bug#12632: file permissions checking mishandled when setuid

[Eli Zaretskii]

> Date: Mon, 22 Oct 2012 22:07:16 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: rgm@gnu.org, 12632@debbugs.gnu.org
> 
> Which of the following calls can fail on Windows in the current
> Emacs trunk, and why?
> 
>    sys_access ("/", D_OK)     sys_access ("/.", D_OK)
>    sys_access ("\\", D_OK)    sys_access ("\\.", D_OK)
>    sys_access ("//", D_OK)    sys_access ("//.", D_OK)
>    sys_access ("/\\", D_OK)   sys_access ("/\\.", D_OK)
>    sys_access ("\\/", D_OK)   sys_access ("\\/.", D_OK)
>    sys_access ("\\\\", D_OK)  sys_access ("\\\\.", D_OK)
>    sys_access ("///", D_OK)   sys_access ("///.", D_OK)

Sorry, I cannot afford doing this research.  Some of these file names
have no meaning at all, so they are prone to undefined behavior.
Others, like "//.", are downright dangerous, because "\\.\" begins a
device name on Windows.  With these arcana notoriously
under-documented by MS, it is anybody's guess what such names can do
in what APIs.

I'm trying to avoid potential problems before they have a chance to
screw some user.  I don't see a reason to seek a 110% provable test
case, when the issue at hand is a single use of a macro that is used
all over the place in Emacs.

There isn't a single comparison with a literal '/' in fileio.c, with
the sole exception of supporting the "/:" magic.  More than 50
instances of IS_DIRECTORY_SEP, just in that one file (and several
dozens more elsewhere in Emacs), are the evidence that
IS_DIRECTORY_SEP _is_ the norm, whereas a literal slash is an
exception.  Contrary to your original claim, using '/' will confuse
the reader into thinking that this particular function does something
special, like the code which looks for the "/:" magic, while using
IS_DIRECTORY_SEP will look like any other code we have, and will also
DTRT instead of relying on "maybe it will work".

> > The call to faccessat could fail, just because of the "\/." at the
> > end of the file name.
> 
> Sorry, I don't follow this example.  The code doesn't append
> backslash-slash-dot; it appends slash-dot.  Are you saying that
> in the current trunk, sys_access ("\\", D_OK) can succeed
> but sys_access ("\\/.", D_OK) can fail when presented with
> the same file system?

No, I'm saying that if the function is called with "d:\foo\", it will
call faccessat with "d:\foo\/." as the argument, which has "\/." at
the end of the file name.  Testing with IS_DIRECTORY_SEP will avoid
this and call faccessat with "d:\foo/.".  The latter is a valid file
name, while the former is not.