Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: golang/glog
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v1.2.2
Choose a base ref
...
head repository: golang/glog
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: v1.2.4
Choose a head ref
  • 5 commits
  • 5 files changed
  • 1 contributor

Commits on Nov 4, 2024

  1. glog: check that stderr is valid before using it by default (#72)

    Windows Services are [spawned without `stdout` and `stderr`](https://learn.microsoft.com/en-us/windows/console/getstdhandle#return-value:~:text=If%20an%20application%20does%20not%20have%20associated%20standard%20handles%2C%20such%20as%20a%20service%20running%20on%20an%20interactive%20desktop%2C%20and%20has%20not%20redirected%20them%2C%20the%20return%20value%20is%20NULL.), so any attempt to use them equates to referencing an invalid file `Handle`. `stderrSink` returns the error, which makes `logsink` trigger the termination of the process. The result is that any call to `log.Error` (or `log.Fatal`) from a Windows Service will always crash the program.
    
    This approach checks that `os.Stderr`'s embedded file descriptor (`Handle`, for Windows) is non-NULL once during `init` to determine its validity and if it fails, then never registers `stderrSink` as a logsink.
    
    Disabling based upon whether `os.Stderr` is NULL was chosen because it's precise, doesn't actually influence the result of any output and doesn't require any syscalls, but still detects the case in which `stderr` is unavailable on Windows.
    
    A rejected approach here would've been to swallow the errors from `stderrSink.Emit`, thus sparing us program termination at the hands of `logsink`. I rejected this approach because it felt like it could result in some subtle behavioral changes. For example, invoking `log.Error` after `os.Stderr.Close()` would no longer exit the program and that felt like a non-trivial change (although I can think of no reason why one would desire this behavior).
    
    cl/680817112 (google-internal)
    chressie authored Nov 4, 2024
    Configuration menu
    Copy the full SHA
    459cf3b View commit details
    Browse the repository at this point in the history

Commits on Nov 5, 2024

  1. glog: fix typo (#73)

    cl/648345242 (google-internal)
    chressie authored Nov 5, 2024
    Configuration menu
    Copy the full SHA
    04dbec0 View commit details
    Browse the repository at this point in the history

Commits on Jan 13, 2025

  1. glog: Don't try to create/rotate a given syncBuffer twice in the same…

    … second
    
    If you do, then you truncate the existing file. So logging too much too quickly would lose log data.
    
    cl/709080575 (google-internal)
    chressie authored and stapelberg committed Jan 13, 2025
    Configuration menu
    Copy the full SHA
    dd58629 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    7139da2 View commit details
    Browse the repository at this point in the history
  3. glog: have createInDir fail if the file already exists

    This prevents an attack like the one described
    [here](https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File#:~:text=On%20Unix%20based,with%20elevated%20permissions.).
    An unprivileged attacker could use symlinks to trick a privileged
    logging process to follow a symlink from the log dir and write logs over
    an arbitrary file.
    
    The components of the log names are program, host, username, tag, date,
    time and PID. These are all predictable. It's not at all unusual for the
    logdir to be writable by unprivileged users, and one of the fallback
    directories (/tmp) traditionally has broad write privs with the sticky
    bit set on Unix systems.
    
    As a concrete example, let's say I've got a glog-enabled binary running
    as a root cronjob. I can gauge when that cron job will run and then use
    a bash script to spray the log dir with glog-looking symlinks to
    `/etc/shadow` with predicted times and PIDs. When the cronjob runs, the
    `os.Create` call will follow the symlink, truncate `/etc/shadow` and
    then fill it with logs.
    
    This change defeats that by setting `O_EXCL`, which will cause the open
    call to fail if the file already exists.
    
    Fixes CVE-2024-45339
    
    cl/712795111 (google-internal)
    chressie authored and stapelberg committed Jan 13, 2025
    Configuration menu
    Copy the full SHA
    a0e3c40 View commit details
    Browse the repository at this point in the history
Loading