On Nov  4 11:30, Matt D. wrote:
> On 11/4/2017 9:31 AM, Matt D. wrote:
> > On 11/4/2017 7:47 AM, Matt D. wrote:
> > > On 11/4/2017 7:37 AM, Corinna Vinschen wrote:
> > > > On Nov  4 05:47, Matt D. wrote:
> > > > > I mount with "noacl" as I don't need ACLs for my purposes and prefer to
> > > > > leave everything up to Windows permissions.
> > > > > 
> > > > > The problem with this is that ssh insists that ~/.ssh/config be less
> > > > > permissive. But this file is bound to --rw-r--r-- for this option.
> > > > > 
> > > > > Would it be appropriate to request ssh to ignore this requirement when
> > > > > "noacl" present on the mounted volume?
> > > > 
> > > > Yes, in theory.  However, this shouldn't be necessary.
> > > > 
> > > > Ssh already has code to check extrem perms only in "acl" mounted
> > > > directories, but it does not have this extra check for config files,
> > > > basically because it was never necessary:
> > > > 
> > > > If you use noacl, your file perms are faked to always be 644, or
> > > > 444 if the DOS R/O bit is set, or 755/555 if executable/directory.
> > > > Additionally all files are faked as if they are owned by your own
> > > > account.
> > > > 
> > > > Ssh checks the config file like this:
> > > > 
> > > >    if (((sb.st_uid != 0 && sb.st_uid != getuid()) ||
> > > >        (sb.st_mode & 022) != 0))
> > > >       fatal("Bad owner or permissions on %s", filename);
> > > > 
> > > > Which means, 0644 permissions are perfectly fine.  As are 755 perms
> > > > for the ~/.ssh and ~ dirs.
> > > > 
> > > > I just mounted my home dir "noacl".  The perms are as expected:
> > > > 
> > > >    $ ls -ld . .ssh .ssh/config .ssh/id_local
> > > >    drwxr-xr-x 1 corinna vinschen    0 Nov  4 12:27 .
> > > >    drwxr-xr-x 1 corinna vinschen    0 Mar 14  2017 .ssh
> > > >    -rw-r--r-- 1 corinna vinschen  703 Jan 19  2017 .ssh/config
> > > >    -rw-r--r-- 1 corinna vinschen 7329 Jan 12  2017 .ssh/id_local
> > > > 
> > > > Note especially the too open perms in case of the private keyfile
> > > > "id_local".  Still, I can ssh into one of my other machines just fine.
> > > > 
> > > > How come this doesn't work for you?
> > > > [...]
> 
> The code "sb.st_mode & 022" will always be true unless the group and other
> bits are set to 0. So 755, 644, 555, or whatever would not work.

The test is (sb.st_mode & 022) != 0  and that checks if write perms for
group or other are set.  If so, your perms are too open.  Given that
perms are always faked as 644 under "noacl", that test is entirely
sufficient.

> I made a test build which output the value of sb.st_mode and it displayed as
> "100770". This value reflected the actual NTFS ACLs and not what was
> displayed at the bash prompt or by "stat -c %a" (which says 644).

There's a disconnection here.  Consider:  Where's ls getting the values
from, if not by calling stat?

If your build does not show the same values, then I *bet*, your test
application is not using the same path as if you're using the coreutils
stat tool.  Apparently they access the file via different mount points,
one of them "acl", the other "noacl".

> This makes sense because Cygwin is pulling the NTFS permissions as there are
> no Cygwin ACLs defined.

That's'a misconception.  Cygwin ACLs *are* Windows ACLs.  There is only
one type of ACLs under the hood, and that are the ACLs stored as
metadata by the OS.  Cygwin, as a userspace DLL, just creates ACLs which
resemble POSIX permissions.  But that doesn't change the fact that these
ACLs are system ACLs.

Again:

- On "acl" mounts Cygwin uses the underlying Windows ACLs to load and
  store *real* access information.

- On "noacl" mounts Cygwin never actually read ACLs.  It just fakes
  permission bits based on the DOS R/O bit and the file type.  And
  it always fakes ownership so ls -l claims you are the owner of
  every file on your system, as long as the path goes via the "noacl"
  mount point.

> The only workaround is to use Window's Security diaglog to disable inherited
> permissions and remove the Users group. This does seem to satisfy things.
> 
> I suppose the argument now is whether this behavior should change in the
> face of a drive mounted with "noacl". It took a bit of guesswork as neither
> chmod or setfacl was changing the NTFS permissions.

The problem is that you only look at this from the ssh perspective,
not from the Cygwin DLL perspective.  I can *guarantee* you that a
"noacl" mount point behaves as described above.  The only explanation
making sense here is that you think you're accessing a file via a
"noacl" mount, but actually you're not.  Check your system, and if
you're still in doubt, check the Cygwin source.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat