No way to use ssh ~/.ssh/config with "noacl" option

No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

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?


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

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?


Corinna

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

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?
>
>
> Corinna
>

I don't know why it doesn't work for me other than the reported error. I 
am trying to use ssh combined with git. My .ssh permissions are:

$ls -ld . .ssh .ssh/config .ssh/github
drwxr-xr-x 1 Matthew D'Onofrio None    0 Nov  4 06:42 .
drwxr-xr-x 1 Matthew D'Onofrio None    0 Nov  4 04:51 .ssh
-rw-r--r-- 1 Matthew D'Onofrio None   80 Nov  4 04:51 .ssh/config
-rw-r--r-- 1 Matthew D'Onofrio None 3243 Nov  3 10:53 .ssh/github

I removed the noacl option in fstab, re-ran Cygwin setup, set 
.ssh/config to 600 and ssh was happy. I then reverted back to noacl and 
the problem returned.

I'm in the process of trying to build openssh with cygpath for debugging 
but this is my first time building anything from Cygwin or using 
cygports so it's taking some time.


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

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?
>>
>>
>> Corinna
>>
>
> I don't know why it doesn't work for me other than the reported error. I
> am trying to use ssh combined with git. My .ssh permissions are:
>
> $ls -ld . .ssh .ssh/config .ssh/github
> drwxr-xr-x 1 Matthew D'Onofrio None    0 Nov  4 06:42 .
> drwxr-xr-x 1 Matthew D'Onofrio None    0 Nov  4 04:51 .ssh
> -rw-r--r-- 1 Matthew D'Onofrio None   80 Nov  4 04:51 .ssh/config
> -rw-r--r-- 1 Matthew D'Onofrio None 3243 Nov  3 10:53 .ssh/github
>
> I removed the noacl option in fstab, re-ran Cygwin setup, set
> .ssh/config to 600 and ssh was happy. I then reverted back to noacl and
> the problem returned.
>
> I'm in the process of trying to build openssh with cygpath for debugging
> but this is my first time building anything from Cygwin or using
> cygports so it's taking some time.
>
>
> Matt D.

Please stand by. Looking into this further.


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

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?
>>>
>>>
>>> Corinna
>>>
>>
>> I don't know why it doesn't work for me other than the reported error. I
>> am trying to use ssh combined with git. My .ssh permissions are:
>>
>> $ls -ld . .ssh .ssh/config .ssh/github
>> drwxr-xr-x 1 Matthew D'Onofrio None    0 Nov  4 06:42 .
>> drwxr-xr-x 1 Matthew D'Onofrio None    0 Nov  4 04:51 .ssh
>> -rw-r--r-- 1 Matthew D'Onofrio None   80 Nov  4 04:51 .ssh/config
>> -rw-r--r-- 1 Matthew D'Onofrio None 3243 Nov  3 10:53 .ssh/github
>>
>> I removed the noacl option in fstab, re-ran Cygwin setup, set
>> .ssh/config to 600 and ssh was happy. I then reverted back to noacl and
>> the problem returned.
>>
>> I'm in the process of trying to build openssh with cygpath for debugging
>> but this is my first time building anything from Cygwin or using
>> cygports so it's taking some time.
>>
>>
>> Matt D.
>
> Please stand by. Looking into this further.
>
>
> Matt D.

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.

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).

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

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.

Interestingly, a config file that I chmodded when the drive was mounted 
with Cygwin ACLs still works with ssh even though "noacl" is now defined 
and it is still part of the HOSTNAME\Users group. Neither stat or 
getfacl show these permissions but they can be seen in the security tab 
of the file properties. I'm guessing that it works because it has 
HOSTNAME\None below HOSTNAME\<my account> or something?


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Achim Gratz]

Matt D. writes:
> This makes sense because Cygwin is pulling the NTFS permissions as
> there are no Cygwin ACLs defined.
>
> 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.

That's the correct thing to do, even though you made this unnecessarily
hard for yourself by mounting your home directory with "noacl".

> 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.

I don't think ssh should use files that are accessible by somebody
else.  The noacl mount option is sometimes useful, but certainly not in
this situation, as you found out.

> Interestingly, a config file that I chmodded when the drive was
> mounted with Cygwin ACLs still works with ssh even though "noacl" is
> now defined and it is still part of the HOSTNAME\Users group. Neither
> stat or getfacl show these permissions but they can be seen in the
> security tab of the file properties. I'm guessing that it works
> because it has HOSTNAME\None below HOSTNAME\<my account> or something?

The effective access rights as shown by icacls or similar tools should
tell you what is going on.  If the directory is not readable, then the
file is effectively inaccessible I think.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

On 11/4/2017 11:43 AM, Achim Gratz wrote:
> That's the correct thing to do, even though you made this unnecessarily
> hard for yourself by mounting your home directory with "noacl".

It's not perfect but I've always had trouble with all of the 
modifications Cygwin makes to a file's permissions to support 
POSIX-style ACLs. I do miss being able to manage them with chmod and 
setfacl though.

For those wishing to set their ssh config to 600 (as recognized by 
Cygwin's ssh), use the following:

Reset file permissions:
   icacls config /t /q /c /reset

Inheritence must be disabled to alter other groups:
   icacls config /inheritance:d

Effectively regarded as "group":
   icacls config /remove:g "Authenticated Users"
   icacls config /remove:g "Users"

Regarded as "other":
   icacls config /remove:g "Everyone"

Add the current user as the owner:
   icacls config /grant "%USERNAME%:rw"


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Achim Gratz]

Matt D. writes:
> It's not perfect but I've always had trouble with all of the
> modifications Cygwin makes to a file's permissions to support
> POSIX-style ACLs. I do miss being able to manage them with chmod and
> setfacl though.

Just remove any ACL inheritance on the home directory before populating
it (or recursively remove it for an existing directory, but that can be
more tricky).  I suggest to use a sub-directory of your actual Windows
home, otherwise you might get into trouble with applications writing dot
files into it and/or getting confused by the dot files from Cygwin.
It's easy enough to mount it to /home/$USER so it's where you'd normally
expect it to show up.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Brian Inglis]

On 2017-11-04 12:25, Achim Gratz wrote:
> Matt D. writes:
>> It's not perfect but I've always had trouble with all of the
>> modifications Cygwin makes to a file's permissions to support
>> POSIX-style ACLs. I do miss being able to manage them with chmod and
>> setfacl though.
> 
> Just remove any ACL inheritance on the home directory before populating
> it (or recursively remove it for an existing directory, but that can be
> more tricky).  I suggest to use a sub-directory of your actual Windows
> home, otherwise you might get into trouble with applications writing dot
> files into it and/or getting confused by the dot files from Cygwin.
> It's easy enough to mount it to /home/$USER so it's where you'd normally
> expect it to show up.

If you remove the DACLs on directories, you will be unable to access any files
without using Cygwin, as Windows sees no permissions, and any files created by
Windows programs will have no Cygwin permissions, and you will be unable to
access those files from Cygwin or Windows programs, without doing manual Windows
security fixups.
I've hit some directories with setfacl -bk, and quickly regretted it.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4940 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

On 11/4/2017 12:37 PM, Corinna Vinschen wrote:
> 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".

Ssh's readconf.c is using fstat(). If these results are more accurate 
with "noacl" defined then why always say "-rw-r--r--" when more 
information is available?


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

On 11/4/2017 1:15 PM, Matt D. wrote:
 > On 11/4/2017 11:43 AM, Achim Gratz wrote:
 >> That's the correct thing to do, even though you made this unnecessarily
 >> hard for yourself by mounting your home directory with "noacl".
 >
 > It's not perfect but I've always had trouble with all of the
 > modifications Cygwin makes to a file's permissions to support
 > POSIX-style ACLs. I do miss being able to manage them with chmod and
 > setfacl though.
 >
 > For those wishing to set their ssh config to 600 (as recognized by
 > Cygwin's ssh), use the following:
 >
 > Reset file permissions:
 >    icacls config /t /q /c /reset
 >
 > Inheritence must be disabled to alter other groups:
 >    icacls config /inheritance:d
 >
 > Effectively regarded as "group":
 >    icacls config /remove:g "Authenticated Users"
 >    icacls config /remove:g "Users"
 >
 > Regarded as "other":
 >    icacls config /remove:g "Everyone"
 >
 > Add the current user as the owner:
 >    icacls config /grant "%USERNAME%:rw"
 >
 >
 > Matt D.

My previous reply was missing "takeown" to take ownership. The correct 
sequence of commands is:

icacls config /t /q /c /reset
icacls config /inheritance:d
takeown /f config
icacls config /remove:g "Authenticated Users"
icacls config /remove:g "Users"
icacls config /remove:g "Everyone"
icacls config /grant "%USERNAME%:rw"

This is equivalent to "chmod 600 config".


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: No way to use ssh ~/.ssh/config with "noacl" option

[Matt D.]

On 11/4/2017 1:38 PM, Matt D. wrote:
> On 11/4/2017 1:15 PM, Matt D. wrote:
>  > On 11/4/2017 11:43 AM, Achim Gratz wrote:
>  >> That's the correct thing to do, even though you made this unnecessarily
>  >> hard for yourself by mounting your home directory with "noacl".
>  >
>  > It's not perfect but I've always had trouble with all of the
>  > modifications Cygwin makes to a file's permissions to support
>  > POSIX-style ACLs. I do miss being able to manage them with chmod and
>  > setfacl though.
>  >
>  > For those wishing to set their ssh config to 600 (as recognized by
>  > Cygwin's ssh), use the following:
>  >
>  > Reset file permissions:
>  >    icacls config /t /q /c /reset
>  >
>  > Inheritence must be disabled to alter other groups:
>  >    icacls config /inheritance:d
>  >
>  > Effectively regarded as "group":
>  >    icacls config /remove:g "Authenticated Users"
>  >    icacls config /remove:g "Users"
>  >
>  > Regarded as "other":
>  >    icacls config /remove:g "Everyone"
>  >
>  > Add the current user as the owner:
>  >    icacls config /grant "%USERNAME%:rw"
>  >
>  >
>  > Matt D.
>
> My previous reply was missing "takeown" to take ownership. The correct
> sequence of commands is:
>
> icacls config /t /q /c /reset
> icacls config /inheritance:d
> takeown /f config
> icacls config /remove:g "Authenticated Users"
> icacls config /remove:g "Users"
> icacls config /remove:g "Everyone"
> icacls config /grant "%USERNAME%:rw"
>
> This is equivalent to "chmod 600 config".
>
>
> Matt D.

Here is a more portable version of taking ownership and setting 
permissions to 600. It uses SIDs instead of literal names which may vary 
between locale:

icacls "id_rsa" /t /q /c /reset
icacls "id_rsa" /inheritance:d
takeown /f "id_rsa"
icacls "id_rsa" /remove *S-1-5-11
icacls "id_rsa" /remove *S-1-5-32-545
icacls "id_rsa" /remove *S-1-1-0
icacls "id_rsa" /grant "%USERNAME%:rw"

S-1-5-11 (Authenticated Users group)
S-1-5-32-545 (Users group)
S-1-1-0 (Everyone group)


Matt D.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple