bug#12632: file permissions checking mishandled when setuid

[Paul Eggert]

On 10/22/2012 08:47 PM, Eli Zaretskii wrote:
>> > Is it possible in Windows that the searchability of the file named "//"
>> > differs from the searchability of "/"?  Or that the searchability
>> > of "\/" differs from that of "\"?
> Both is true.  // or \\ or \/ starts a UNC, and Windows expects the
> following to be the name of a remote machine.  / or \ is just the root
> directory of the current drive.

Sorry, apparently I wasn't clear.  I wasn't asking about names like
//remotemachine or /directory, as names like that should not be
affected by this issue.  I was asking about bare // and bare /
and their aliases with backslash.  Let me try to be more concrete.
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)

>> Can you give an example of how that might affect the test?
> 
> 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?