Re: upcalls seem to have problems with symlinks, junctions et al.

[L A Walsh <cifs@tlinx.org>]

On 2/21/2019 8:30 PM, Steve French wrote:
> I have wanted to change this code and improve it for a while - one
> thing which is tricky is showing mode bits when no permissions to read
> permissions though,
>   
---
    How often would it be the case that you could read the content
of a directory, but not be able to read the permissions? 

    While that can happen on Windows... and not so much on linux
what is the content of the link considered?  I.e. where it is pointing?
Is that something that would usually be readable because it is
pointing to the next item in the path and most people have
the privilege to "Bypass Traverse Checking"?

    I.e. -- is the access to the path information in a symlink controlled
by read permissions to item content, or is it considered part of the
information needed for Traverse Checking?

    I think my issue I had in Feb 2017 had to do with getting
different results depending on the type of the redirect -- junctions,
mountd/vol, and symlink/symlinkd's -- and perhaps that might be
related to how they store store the meta-information?  I suppose
there is similar redirect information at a DFS mount point?

    Part of what I expect, "as a user", to be available to a remote
user, is based on how things look from a user perspective using the
POSIXish-designed-Cygwin.  If I'm signed in with the same
domain-credential (and same SID), remotely, vs. locally, my
expectation is that I should see the same access.  That forms my
expectations with CIFS.