Commits on Mar 28, 2020

1. nginx: Fix ETag patch to ignore realpath(3) error …

   While our ETag patch works pretty fine if it comes to serving data off
   store paths, it unfortunately broke something that might be a bit more
   common, namely when using regexes to extract path components of
   location directives for example.
   
   Recently, @devhell has reported a bug with a nginx location directive
   like this:
   
     location ~^/\~([a-z0-9_]+)(/.*)?$" {
       alias /home/$1/public_html$2;
     }
   
   While this might look harmless at first glance, it does however cause
   issues with our ETag patch. The alias directive gets broken up by nginx
   like this:
   
     *2 http script copy: "/home/"
     *2 http script capture: "foo"
     *2 http script copy: "/public_html/"
     *2 http script capture: "bar.txt"
   
   In our patch however, we use realpath(3) to get the canonicalised path
   from ngx_http_core_loc_conf_s.root, which returns the *configured* value
   from the root or alias directive. So in the example above, realpath(3)
   boils down to the following syscalls:
   
     lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
     lstat("/home/$1", 0x7ffd08da6f60) = -1 ENOENT (No such file or directory)
   
   During my review[1] of the initial patch, I didn't actually notice that
   what we're doing here is returning NGX_ERROR if the realpath(3) call
   fails, which in turn causes an HTTP 500 error.
   
   Since our patch actually made the canonicalisation (and thus additional
   syscalls) necessary, we really shouldn't introduce an additional error
   so let's - at least for now - silently skip return value if realpath(3)
   has failed.
   
   However since we're using the unaltered root from the config we have
   another issue, consider this root:
   
     /nix/store/...-abcde/$1
   
   Calling realpath(3) on this path will fail (except if there's a file
   called "$1" of course), so even this fix is not enough because it
   results in the ETag not being set to the store path hash.
   
   While this is very ugly and we should fix this very soon, it's not as
   serious as getting HTTP 500 errors for serving static files.
   
   I added a small NixOS VM test, which uses the example above as a
   regression test.
   
   It seems that my memory is failing these days, since apparently I *knew*
   about this issue since digging for existing issues in nixpkgs, I found
   this similar pull request which I even reviewed:
   
   NixOS/nixpkgs#66532
   
   However, since the comments weren't addressed and the author hasn't
   responded to the pull request, I decided to keep this very commit and do
   a follow-up pull request.
   
   [1]: NixOS/nixpkgs#48337
   
   Signed-off-by: aszlig <aszlig@nix.build>
   Reported-by: @devhell
   Acked-by: @7c6f434c
   Acked-by: @yorickvP
   Merges: NixOS/nixpkgs#80671
   Fixes: NixOS/nixpkgs#66532
   (cherry picked from commit e1d63ad)

   

   aszlig committed Mar 28, 2020
   Copy the full SHA

   598a9cb View commit details

   Browse the repository at this point in the history