Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Brian Buchanan]

On Thu, 30 Apr 2015 at 10:24:50, Corinna Vinschen <corinna-cygwin at
cygwin dot com> wrote:
>
> On Apr 29 10:45, Brian Buchanan wrote:
> > I did a fresh cygwin-64 (setup-x86_64 version 2.870) install under
> > build 10061 of Windows 10 Technical Preview.
> >
> > The group permissions in the root look wrong.
> >
> > $ ls -lA /
> > total 321
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 bin
> > dr-xr-xr-x  1 Brian Brian               0 Apr 29 10:31 cygdrive
> > -rwxr-xr-x  1 Brian Administrators     59 Apr 29 10:31 Cygwin.bat
> > -rw-r--r--  1 Brian Administrators 157097 Apr 29 10:31 Cygwin.ico
> > -rw-r--r--  1 Brian Administrators  53342 Apr 29 10:31 Cygwin-Terminal.ico
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 dev
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 etc
> > drwx---rwt+ 1 Brian Brian               0 Apr 29 10:31 home
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 lib
> > dr-xr-xr-x  9 Brian Brian               0 Apr 29 10:31 proc
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 sbin
> > drwx---rwt+ 1 Brian Brian               0 Apr 29 10:31 tmp
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:30 usr
> > drwx---r-x+ 1 Brian Brian               0 Apr 29 10:30 var
> >
> > I'm logged on with a Microsoft account and ran the installer as an
> > Administrator.
> >
> > This is a particular problem running ssh-host-config -y
> > $ ssh-host-config -y
> >
...
> > /usr/share/doc/openssh/README.privsep.
> > *** Query: Should privilege separation be used? (yes/no) yes
> > *** Warning: The permissions on the directory /var are not correct.
> > *** Warning: They must match the regexp d..x..x..[xt]
> > *** ERROR: Problem with /var directory. Exiting.
>
> Hmm, the permission test in the csih helper script is apparently not up
> to the task in your situation.  As a workaround, you may want to change
> the group ownership of /var/empty to "Users" and chmod it to 755, then
> run the ssh-host-config script again.
>

(I'm now on a fresh install of Build 10130)

I had to do that to /var (not just /var/empty) to get past that
message, but I've run into another snag with ssh-host-config

I'm getting an errors saying unknown user win-g71n7drq4r6+cyg_server
at the point of setting the password, the password expiry and
assigning permissions.

*** Info: This script plans to use 'cyg_server'.
*** Info: 'cyg_server' will only be used by registered services.
*** Query: Create new privileged user account
'WIN-G71N7DRQ4R6\cyg_server' (Cygwin name:
'win-g71n7drq4r6+cyg_server')? (yes/no) yes
*** Info: Please enter a password for new user
win-g71n7drq4r6+cyg_server.  Please be sure
*** Info: that this password matches the password rules given on your system.
*** Info: Entering no password will exit the configuration.
*** Query: Please enter the password:
*** Query: Reenter:

*** Info: User 'win-g71n7drq4r6+cyg_server' has been created with
password 'Su3per$ecr3t'.
*** Info: If you change the password, please remember also to change the
*** Info: password for the installed services which use (or will soon use)
*** Info: the 'win-g71n7drq4r6+cyg_server' account.

passwd: unknown user win-g71n7drq4r6+cyg_server
*** Warning: Setting password expiry for user
'win-g71n7drq4r6+cyg_server' failed!
*** Warning: Please check that password never expires or set it to your needs.
No user or group 'win-g71n7drq4r6+cyg_server' known.
*** Warning: Assigning the appropriate privileges to user
'win-g71n7drq4r6+cyg_server' failed!
*** ERROR: There was a serious problem creating a privileged user.
*** Query: Do you want to proceed anyway? (yes/no) yes
*** Warning: Expected privileged user 'win-g71n7drq4r6+cyg_server'
does not exist.
*** Warning: Defaulting to 'SYSTEM'

*** Info: The sshd service has been installed under the LocalSystem
*** Info: account (also known as SYSTEM). To start the service now, call
*** Info: `net start sshd' or `cygrunsrv -S sshd'.  Otherwise, it
*** Info: will start automatically after the next reboot.

*** Warning: Host configuration exited with 1 errors or warnings!
*** Warning: Make sure that all problems reported are fixed,
*** Warning: then re-run ssh-host-config.

At this point sshd and a cyg_server accounts exist and the service got
created, however it's using the Local System account.

The Service starts ok, but terminates ssh connections.

The event log shows:
sshd: PID 11620: fatal: seteuid 197609: Operation not permitted.

I'm guessing this is just because the Local System account doesn't
have the required privileges.

What do those processes (passwd, set password expiry and assigning
appropriate privileges) need to succeed?

Brian

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Jun 16 09:23, Brian Buchanan wrote:
> On Thu, 30 Apr 2015 at 10:24:50, Corinna Vinschen <corinna-cygwin at
> cygwin dot com> wrote:
> >[...]
> > Hmm, the permission test in the csih helper script is apparently not up
> > to the task in your situation.  As a workaround, you may want to change
> > the group ownership of /var/empty to "Users" and chmod it to 755, then
> > run the ssh-host-config script again.
> >
> 
> (I'm now on a fresh install of Build 10130)
> 
> I had to do that to /var (not just /var/empty) to get past that
> message, but I've run into another snag with ssh-host-config
> 
> I'm getting an errors saying unknown user win-g71n7drq4r6+cyg_server
> at the point of setting the password, the password expiry and
> assigning permissions.

This is a domain member machine, yes?

> *** Info: This script plans to use 'cyg_server'.
> *** Info: 'cyg_server' will only be used by registered services.
> *** Query: Create new privileged user account
> 'WIN-G71N7DRQ4R6\cyg_server' (Cygwin name:
> 'win-g71n7drq4r6+cyg_server')? (yes/no) yes
> *** Info: Please enter a password for new user
> win-g71n7drq4r6+cyg_server.  Please be sure
> *** Info: that this password matches the password rules given on your system.
> *** Info: Entering no password will exit the configuration.
> *** Query: Please enter the password:
> *** Query: Reenter:
> 
> *** Info: User 'win-g71n7drq4r6+cyg_server' has been created with
> password 'Su3per$ecr3t'.
> *** Info: If you change the password, please remember also to change the
> *** Info: password for the installed services which use (or will soon use)
> *** Info: the 'win-g71n7drq4r6+cyg_server' account.
> 
> passwd: unknown user win-g71n7drq4r6+cyg_server
> *** Warning: Setting password expiry for user
> 'win-g71n7drq4r6+cyg_server' failed!

This is weird.  The same works for me:

  *** Query: Do you want to use a different name? (yes/no) yes
  *** Query: Enter the new user name: blubber
  *** Query: Reenter: blubber

  *** Query: Create new privileged user account 'my_machine\blubber' (Cygwin name: 'my_machine+blubber')? (yes/no) yes
  *** Info: Please enter a password for new user my_machine+blubber.  Please be sure
  *** Info: that this password matches the password rules given on your system.
  *** Info: Entering no password will exit the configuration.
  *** Query: Please enter the password:
  *** Query: Reenter:

  *** Info: User 'my_machine+blubber' has been created with password 'blubber'.
  *** Info: If you change the password, please remember also to change the
  *** Info: password for the installed services which use (or will soon use)
  *** Info: the 'my_machine+blubber' account.


  *** Info: The sshd service has been installed under the 'my_machine+blubber'
  *** Info: account.  To start the service now, call `net start sshd' or
  *** Info: `cygrunsrv -S sshd'.  Otherwise, it will start automatically
  *** Info: after the next reboot.

  *** Info: Host configuration finished. Have fun!

Is there a chance you have a non-Cygwin passwd tool in $PATH?

> [...]
> At this point sshd and a cyg_server accounts exist and the service got
> created, however it's using the Local System account.

You can change that in the Services GUI to the local cyg_server user.

> I'm guessing this is just because the Local System account doesn't
> have the required privileges.

Yes.

> What do those processes (passwd, set password expiry and assigning
> appropriate privileges) need to succeed?

I don't know why this occurs.  As you can see above, it works for me.

This is a completely new setup with the Cygwin distro updated to the
latest?  csih 0.9.8-6?  cygwin-2.0.4-1?


Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Takashi Yano]

Hi Corinna,

Is there any progress regarding this problem?

I recently encountered the same situation. After some trials,
I found this problem occurs if the account, on which cygwin
setup is executed, is a Microsoft account. This does not occur
if the account is a local account.

Above is true for both:
a) Group permissions on root folders
b) Creating sshd service using cyg_server

I would be happy if this information helps you.


On Tue, 16 Jun 2015 17:58:43 +0200
Corinna Vinschen wrote:

> On Jun 16 09:23, Brian Buchanan wrote:
> > On Thu, 30 Apr 2015 at 10:24:50, Corinna Vinschen <corinna-cygwin at
> > cygwin dot com> wrote:
> > >[...]
> > > Hmm, the permission test in the csih helper script is apparently not up
> > > to the task in your situation.  As a workaround, you may want to change
> > > the group ownership of /var/empty to "Users" and chmod it to 755, then
> > > run the ssh-host-config script again.
> > >
> > 
> > (I'm now on a fresh install of Build 10130)
> > 
> > I had to do that to /var (not just /var/empty) to get past that
> > message, but I've run into another snag with ssh-host-config
> > 
> > I'm getting an errors saying unknown user win-g71n7drq4r6+cyg_server
> > at the point of setting the password, the password expiry and
> > assigning permissions.
> 
> This is a domain member machine, yes?
> 
> > *** Info: This script plans to use 'cyg_server'.
> > *** Info: 'cyg_server' will only be used by registered services.
> > *** Query: Create new privileged user account
> > 'WIN-G71N7DRQ4R6\cyg_server' (Cygwin name:
> > 'win-g71n7drq4r6+cyg_server')? (yes/no) yes
> > *** Info: Please enter a password for new user
> > win-g71n7drq4r6+cyg_server.  Please be sure
> > *** Info: that this password matches the password rules given on your system.
> > *** Info: Entering no password will exit the configuration.
> > *** Query: Please enter the password:
> > *** Query: Reenter:
> > 
> > *** Info: User 'win-g71n7drq4r6+cyg_server' has been created with
> > password 'Su3per$ecr3t'.
> > *** Info: If you change the password, please remember also to change the
> > *** Info: password for the installed services which use (or will soon use)
> > *** Info: the 'win-g71n7drq4r6+cyg_server' account.
> > 
> > passwd: unknown user win-g71n7drq4r6+cyg_server
> > *** Warning: Setting password expiry for user
> > 'win-g71n7drq4r6+cyg_server' failed!
> 
> This is weird.  The same works for me:
> 
>   *** Query: Do you want to use a different name? (yes/no) yes
>   *** Query: Enter the new user name: blubber
>   *** Query: Reenter: blubber
> 
>   *** Query: Create new privileged user account 'my_machine\blubber' (Cygwin name: 'my_machine+blubber')? (yes/no) yes
>   *** Info: Please enter a password for new user my_machine+blubber.  Please be sure
>   *** Info: that this password matches the password rules given on your system.
>   *** Info: Entering no password will exit the configuration.
>   *** Query: Please enter the password:
>   *** Query: Reenter:
> 
>   *** Info: User 'my_machine+blubber' has been created with password 'blubber'.
>   *** Info: If you change the password, please remember also to change the
>   *** Info: password for the installed services which use (or will soon use)
>   *** Info: the 'my_machine+blubber' account.
> 
> 
>   *** Info: The sshd service has been installed under the 'my_machine+blubber'
>   *** Info: account.  To start the service now, call `net start sshd' or
>   *** Info: `cygrunsrv -S sshd'.  Otherwise, it will start automatically
>   *** Info: after the next reboot.
> 
>   *** Info: Host configuration finished. Have fun!
> 
> Is there a chance you have a non-Cygwin passwd tool in $PATH?
> 
> > [...]
> > At this point sshd and a cyg_server accounts exist and the service got
> > created, however it's using the Local System account.
> 
> You can change that in the Services GUI to the local cyg_server user.
> 
> > I'm guessing this is just because the Local System account doesn't
> > have the required privileges.
> 
> Yes.
> 
> > What do those processes (passwd, set password expiry and assigning
> > appropriate privileges) need to succeed?
> 
> I don't know why this occurs.  As you can see above, it works for me.
> 
> This is a completely new setup with the Cygwin distro updated to the
> latest?  csih 0.9.8-6?  cygwin-2.0.4-1?
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat


-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Sep  5 15:59, Takashi Yano wrote:
> Hi Corinna,
> 
> Is there any progress regarding this problem?

Considering that I had entirely forgotton about it, no.

> I recently encountered the same situation. After some trials,
> I found this problem occurs if the account, on which cygwin
> setup is executed, is a Microsoft account. This does not occur
> if the account is a local account.
> 
> Above is true for both:
> a) Group permissions on root folders
> b) Creating sshd service using cyg_server
> 
> I would be happy if this information helps you.

Not really.  For privacy reasons I'm not using Windows accounts, so it
would be really nice if somebody could track this down.

The group permission problem is easy (and I'm wondering if it really was
such a bright idea to let user SID == group SID slip through in Cygwin,
rather tnan  sticking to the former idea to change the group SID to
"Users" in this case).  csih needs a patch to not check for the group
x bit if user SID == group SID.

However, I have not the faintest idea why the cyg_server stuff doesn't
work.  Anybody willing to track this down in the csih helper script?


Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Takashi Yano]

Hi Corinna,

> However, I have not the faintest idea why the cyg_server stuff doesn't
> work.  Anybody willing to track this down in the csih helper script?

I had looked into csih script, and found a patch below solves
the second problem.
> > b) Creating sshd service using cyg_server

--- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
+++ cygwin-service-installation-helper.sh	2015-09-10 18:16:38.185042300 +0900
@@ -2867,7 +2867,8 @@
     if ! csih_use_file_etc "passwd"
     then
       # This test succeeds on domain member machines only, not on DCs.
-      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
+      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
+	   -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
       then
 	# Lowercase of USERDOMAIN
       	csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[David A Cobb]

On 2015-09-05 02:59, Takashi Yano wrote:
> Hi Corinna,
>
> Is there any progress regarding this problem?
>
> I recently encountered the same situation. After some trials,
> I found this problem occurs if the account, on which cygwin
> setup is executed, is a Microsoft account. This does not occur
> if the account is a local account.
> I'm getting an errors saying unknown user win-g71n7drq4r6+cyg_server
> at the point of setting the password, the password expiry and
> assigning permissions.
<SNIP />
>> This is a domain member machine, yes?
>>
>>> *** Info: This script plans to use 'cyg_server'.
>>> *** Info: 'cyg_server' will only be used by registered services.
>>> *** Query: Create new privileged user account
>>> I don't know why this occurs.  As you can see above, it works for me.
<SNIP />
>>>
>>> This is a completely new setup with the Cygwin distro updated to the
>>> latest?  csih 0.9.8-6?  cygwin-2.0.4-1?
>>>
>>>
>>> Corinna
>>>
>>> -- 
>>> Corinna Vinschen                  Please, send mails regarding Cygwin to
>>> Cygwin Maintainer                 cygwin AT cygwin DOT com
>>> Red Hat
Possibly related, or perhaps a totally different bug.

On a Windows-10 host: when I use Cygwin *chown***or *chmod *to make 
permission changes, the next time I access the folder-tree from Windows 
Explorer Security tab, it complains that the Access Control List is 
incorrectly ordered and that will cause undesirable results; happy to 
say, it gives me the chance to re-order the ACL.  The usual undesirable 
result is that an app can create a folder /New/ within /T/ but cannot 
create anything within /T/////New/.

Hypothesis: we are indirectly(?) modifying the ACL but are not observing 
whatever Windows expects for ordering.  I know that Windows enforces 
"*deny*" rules before any "*allow*" rules; I do not know what other 
ordering it observes.  I do know that Windows doesn't really consider 
the "group" property the same way POSIX does, FWIW.



--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Ken Brown]

On 9/10/2015 11:49 AM, David A Cobb wrote:
> On a Windows-10 host: when I use Cygwin *chown***or *chmod *to make
> permission changes, the next time I access the folder-tree from Windows
> Explorer Security tab, it complains that the Access Control List is
> incorrectly ordered and that will cause undesirable results; happy to
> say, it gives me the chance to re-order the ACL.  The usual undesirable
> result is that an app can create a folder /New/ within /T/ but cannot
> create anything within /T/////New/.
>
> Hypothesis: we are indirectly(?) modifying the ACL but are not observing
> whatever Windows expects for ordering.  I know that Windows enforces
> "*deny*" rules before any "*allow*" rules; I do not know what other
> ordering it observes.  I do know that Windows doesn't really consider
> the "group" property the same way POSIX does, FWIW.

This is explained in the Cygwin User's Guide:

   https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files

Ken

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Sep 10 20:04, Takashi Yano wrote:
> Hi Corinna,
> 
> > However, I have not the faintest idea why the cyg_server stuff doesn't
> > work.  Anybody willing to track this down in the csih helper script?
> 
> I had looked into csih script, and found a patch below solves
> the second problem.
> > > b) Creating sshd service using cyg_server
> 
> --- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
> +++ cygwin-service-installation-helper.sh	2015-09-10 18:16:38.185042300 +0900
> @@ -2867,7 +2867,8 @@
>      if ! csih_use_file_etc "passwd"
>      then
>        # This test succeeds on domain member machines only, not on DCs.
> -      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
> +      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
> +	   -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
>        then
>  	# Lowercase of USERDOMAIN
>        	csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"

Thanks a lot, much appreciated.  Patch applied.


Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Eric Blake]

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

On 09/10/2015 11:23 AM, Corinna Vinschen wrote:
> On Sep 10 20:04, Takashi Yano wrote:
>> Hi Corinna,
>>
>>> However, I have not the faintest idea why the cyg_server stuff doesn't
>>> work.  Anybody willing to track this down in the csih helper script?
>>
>> I had looked into csih script, and found a patch below solves
>> the second problem.
>>>> b) Creating sshd service using cyg_server
>>
>> --- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
>> +++ cygwin-service-installation-helper.sh	2015-09-10 18:16:38.185042300 +0900
>> @@ -2867,7 +2867,8 @@
>>      if ! csih_use_file_etc "passwd"
>>      then
>>        # This test succeeds on domain member machines only, not on DCs.
>> -      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
>> +      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
>> +	   -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
>>        then
>>  	# Lowercase of USERDOMAIN
>>        	csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
> 
> Thanks a lot, much appreciated.  Patch applied.

[ ... -a ... ] is not portable; there are some inherently ambiguous
situations that it cannot handle. POSIX recommends that you spell it [
... ] && [ ... ] instead.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Sep 10 12:07, Ken Brown wrote:
> On 9/10/2015 11:49 AM, David A Cobb wrote:
> >On a Windows-10 host: when I use Cygwin *chown***or *chmod *to make
> >permission changes, the next time I access the folder-tree from Windows
> >Explorer Security tab, it complains that the Access Control List is
> >incorrectly ordered and that will cause undesirable results; happy to
> >say, it gives me the chance to re-order the ACL.  The usual undesirable
> >result is that an app can create a folder /New/ within /T/ but cannot
> >create anything within /T/////New/.
> >
> >Hypothesis: we are indirectly(?) modifying the ACL but are not observing
> >whatever Windows expects for ordering.  I know that Windows enforces
> >"*deny*" rules before any "*allow*" rules; I do not know what other

Ken's right, the docs explain it basically.

Additionally it's important to stress the fact that Windows does not
actually enforce the so-called "canonical" order.  It does so only in
some circumstances, as in the GUI.  In fact it's only a "nice to have",
not an OS limitation.  The evalation order of ACLs is the only
interesting factor and that works the same way, independently from the
ACL being canonical or not.  Therefore the Cygwin-generated ACLs are not
necessarily canonical, but still valid.

Just *don't* reorder them in the GUI, unless you really know what you're
doing.

> >ordering it observes.  I do know that Windows doesn't really consider
> >the "group" property the same way POSIX does, FWIW.
> 
> This is explained in the Cygwin User's Guide:
> 
>   https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files
> 
> Ken


Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Sep 10 11:27, Eric Blake wrote:
> On 09/10/2015 11:23 AM, Corinna Vinschen wrote:
> > On Sep 10 20:04, Takashi Yano wrote:
> >> Hi Corinna,
> >>
> >>> However, I have not the faintest idea why the cyg_server stuff doesn't
> >>> work.  Anybody willing to track this down in the csih helper script?
> >>
> >> I had looked into csih script, and found a patch below solves
> >> the second problem.
> >>>> b) Creating sshd service using cyg_server
> >>
> >> --- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
> >> +++ cygwin-service-installation-helper.sh	2015-09-10 18:16:38.185042300 +0900
> >> @@ -2867,7 +2867,8 @@
> >>      if ! csih_use_file_etc "passwd"
> >>      then
> >>        # This test succeeds on domain member machines only, not on DCs.
> >> -      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
> >> +      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
> >> +	   -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
> >>        then
> >>  	# Lowercase of USERDOMAIN
> >>        	csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
> > 
> > Thanks a lot, much appreciated.  Patch applied.
> 
> [ ... -a ... ] is not portable; there are some inherently ambiguous
> situations that it cannot handle. POSIX recommends that you spell it [
> ... ] && [ ... ] instead.

Does this matter in this very situation?  This is always running under
bash, btw.  Bash's a requirement for the csih helper script.


Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Eric Blake]

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

On 09/10/2015 11:31 AM, Corinna Vinschen wrote:

>>>> -      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
>>>> +      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
>>>> +	   -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
>>>>        then
>>>>  	# Lowercase of USERDOMAIN
>>>>        	csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
>>>
>>> Thanks a lot, much appreciated.  Patch applied.
>>
>> [ ... -a ... ] is not portable; there are some inherently ambiguous
>> situations that it cannot handle. POSIX recommends that you spell it [
>> ... ] && [ ... ] instead.
> 
> Does this matter in this very situation?  This is always running under
> bash, btw.  Bash's a requirement for the csih helper script.

Because you are at least using bash, you will get consistent behavior;
and because both ... are 3-argument tests, it is unlikely that one of
the tests can be confused with other operators like '(' or ')'.  So, I
guess it's okay to leave it alone here.  But even with bash, the use of
-a can cause problems when testing user-supplied variables that might
happen to expand to text that looks like potential operators.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Sep 10 11:36, Eric Blake wrote:
> On 09/10/2015 11:31 AM, Corinna Vinschen wrote:
> 
> >>>> -      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
> >>>> +      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
> >>>> +	   -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
> >>>>        then
> >>>>  	# Lowercase of USERDOMAIN
> >>>>        	csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
> >>>
> >>> Thanks a lot, much appreciated.  Patch applied.
> >>
> >> [ ... -a ... ] is not portable; there are some inherently ambiguous
> >> situations that it cannot handle. POSIX recommends that you spell it [
> >> ... ] && [ ... ] instead.
> > 
> > Does this matter in this very situation?  This is always running under
> > bash, btw.  Bash's a requirement for the csih helper script.
> 
> Because you are at least using bash, you will get consistent behavior;
> and because both ... are 3-argument tests, it is unlikely that one of
> the tests can be confused with other operators like '(' or ')'.  So, I
> guess it's okay to leave it alone here.  But even with bash, the use of
> -a can cause problems when testing user-supplied variables that might
> happen to expand to text that looks like potential operators.

Feel free to change that in the csih repo.  Csih is under git now,
see https://sourceware.org/git/?p=cygwin-csih.git.  You're in the
cygwin-apps group, so you have checkin rights.

If I didn't mention that before, I'm glad for any help since I only took
over because Chuck disappeared.


Thanks,
Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[David A Cobb]

On 2015-09-10 12:07, Ken Brown wrote:
> On 9/10/2015 11:49 AM, David A Cobb wrote:
>> On a Windows-10 host: when I use Cygwin *chown***or *chmod *to make
>> permission changes, the next time I access the folder-tree from Windows
>> Explorer Security tab, it complains that the Access Control List is
>> incorrectly ordered and that will cause undesirable results; happy to
>> say, it gives me the chance to re-order the ACL.  The usual undesirable
>> result is that an app can create a folder /New/ within /T/ but cannot
>> create anything within /T/////New/.
<SNIP />
>> This is explained in the Cygwin User's Guide:
>
>   https:/cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files
>
> Ken
>
OK, but where the UG says:
<QUOTE >
   * All access denied ACEs *should* precede any access allowed ACE. ACLs
     following this rule are called "canonical".

Note that the last rule is a preference or a definition of correctness. 
It's not an absolute requirement. All Windows kernels will correctly 
deal with the ACL regardless of the order of allow and deny ACEs. The 
second rule is not modified to get the ACEs in the preferred order.

Unfortunately the security tab in the file properties dialog of the 
Windows Explorer insists to rearrange the order of the ACEs to canonical 
order before you can read them. Thank God, the sort order remains 
unchanged if one presses the Cancel button. But don't even *think* of 
pressing OK...
</QUOTE>

What I'm seeing suggests that the statement of Windows (really NTFS?) 
"correctly dealing with this" is no longer correct.  What is more, if I 
do /not/ allow Windows to reorder the rules to its own liking, I cannot 
correct the symptom described about not being able to access files 
within "/New/".

It's all very well to say "don't even think of pressing OK," but IMNSHO 
Cygwin should /_never_/ allow a user to create a situation which is so 
unacceptable to Windows.  It would be better to tell the user "I'm 
sorry, Dave, I'm not able to do that." [Correct quote from Hal of '2001' 
forgotten].  I know that not all settings allowed in POSIX can be 
represented -- so refuse to try setting the things that cannot be 
represented.

I wouldn't mind mounting everything as "noacl," but would that not 
disable even the limited permission settings we can represent?




--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Andrey Repin]

Greetings, Eric Blake!

>>>>> -      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
>>>>> +      if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" \
>>>>> +     -a "${LOGONSERVER}" != "\\\\MicrosoftAccount" ]
>>>>>        then
>>>>>    # Lowercase of USERDOMAIN
>>>>>            csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
>>>>
>>>> Thanks a lot, much appreciated.  Patch applied.
>>>
>>> [ ... -a ... ] is not portable; there are some inherently ambiguous
>>> situations that it cannot handle. POSIX recommends that you spell it [
>>> ... ] && [ ... ] instead.
>> 
>> Does this matter in this very situation?  This is always running under
>> bash, btw.  Bash's a requirement for the csih helper script.

> Because you are at least using bash, you will get consistent behavior;
> and because both ... are 3-argument tests, it is unlikely that one of
> the tests can be confused with other operators like '(' or ')'.  So, I
> guess it's okay to leave it alone here.  But even with bash, the use of
> -a can cause problems when testing user-supplied variables that might
> happen to expand to text that looks like potential operators.

If a script author did not quote the indirect references, it is their fault,
not an inherent "portability issue".
I don't see, how your statement could be valid.
The "[ ... ] && [ ... ]" doesn't mean the same as testing two conditions in
one statement.


-- 
With best regards,
Andrey Repin
Friday, September 11, 2015 02:57:58

Sorry for my terrible english...


--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Eric Blake]

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

On 09/10/2015 06:39 PM, Andrey Repin wrote:

>>>> [ ... -a ... ] is not portable; there are some inherently ambiguous
>>>> situations that it cannot handle. POSIX recommends that you spell it [
>>>> ... ] && [ ... ] instead.
>>>

> 
> If a script author did not quote the indirect references, it is their fault,

No, even with proper quoting, the use of -a and -o creates ambiguous
situations.  For example, a naive read would claim that

test "$var1" -a "$var2"

sets $? to 0 only if both "$var1" and "$var2" are non-empty.  But
according to the POSIX rules, if $var1 is '!' and $var2 is '', then this
MUST be treated as the negation of the unary operator '-a "$var2"', if
the shell has a unary -a (bash does, dash does not).  And in bash's
case, '-a ""' is false (the empty string never exists as a file), so the
negation is true, and you have a case where the -a version returned 0 in
spite of one of the inputs being empty.

To get what you naively wanted, you HAVE to use:

test "$var1" $$ test "$var2"

Another tricky one is

test ! "$var1" -a "$var2"

because some people naively assume it matches C precedence rules to mean:

test \( ! "$var1" \) -a "$var2"

while POSIX claims it means:

test ! \( "$var1" -a "$var2" \)

except that you can't use () to force the precedence, because POSIX says
that 5 or more arguments to test causes unspecified results.  But it is
unambiguous what you meant when you write:

test ! "$var1" && test "$var2"

or

! { test "$var1" && test "$var2"; }


> not an inherent "portability issue".

It is inherently ambiguous to use -a or -o, so using them at all on
unknown user input is risky.  Furthermore, POSIX has explicitly marked
-a and -o to be optional (only XSI systems have to have them) and
obsolete (they may be withdrawn in a future revision of POSIX, because
of their ambiguity problems).  Therefore it is inherently a portability
issue (as different shells have different behaviors, and future shells
may have further different behaviors).

> I don't see, how your statement could be valid.

Then you haven't read POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

> The "[ ... ] && [ ... ]" doesn't mean the same as testing two conditions in
> one statement.

There is no semantic difference to testing in two statements, because [
is a shell builtin. It costs the same amount of work, and zero fork()s,
either way.

If you really are that opposed to using two shell statements, then
remember that we are using bash, and spell it:

[[ ... && ... ]]

rather than using -a.  At least THAT is guaranteed to work sanely,
although it is not (yet) specified by POSIX.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Andrey Repin]

Greetings, Eric Blake!

>>>>> [ ... -a ... ] is not portable; there are some inherently ambiguous
>>>>> situations that it cannot handle. POSIX recommends that you spell it [
>>>>> ... ] && [ ... ] instead.
>>>>

>> 
>> If a script author did not quote the indirect references, it is their fault,

> No, even with proper quoting, the use of -a and -o creates ambiguous
> situations.  For example, a naive read would claim that

> test "$var1" -a "$var2"

> sets $? to 0 only if both "$var1" and "$var2" are non-empty.  But
> according to the POSIX rules, if $var1 is '!' and $var2 is '', then this
> MUST be treated as the negation of the unary operator '-a "$var2"', if
> the shell has a unary -a (bash does, dash does not).  And in bash's
> case, '-a ""' is false (the empty string never exists as a file), so the
> negation is true, and you have a case where the -a version returned 0 in
> spite of one of the inputs being empty.

That's... great.
At the very least, we have a standard we can rely... refer... to... >.< sigh.

Thanks for your thorough explanation, much appreciated!

(And I have a set of scripts to rewrite...)


-- 
With best regards,
Andrey Repin
Friday, September 11, 2015 04:58:51

Sorry for my terrible english...


--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Takashi Yano]

Hi Corinna,

Regarding the first problem:
> > a) Group permissions on root folders

On Sun, 6 Sep 2015 13:44:44 +0200
Corinna Vinschen wrote:
> The group permission problem is easy (and I'm wondering if it really was
> such a bright idea to let user SID == group SID slip through in Cygwin,
> rather tnan  sticking to the former idea to change the group SID to
> "Users" in this case).  csih needs a patch to not check for the group
> x bit if user SID == group SID.

Do you intend a patch like this? I have confirmed that sshd
is successfully installed and works nicely with this patch
under a Microsoft Account.

--- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
+++ cygwin-service-installation-helper.sh	2015-09-11 18:41:56.870882800 +0900
@@ -2442,6 +2442,8 @@
 # ======================================================================
 _csih_setup()
 {
+  local perms="d..x..x..[xt]"
+
   csih_stacktrace "${@}"
   $_csih_trace
   if [ "$_csih_setup_already_called" -eq 0 ]
@@ -2462,7 +2464,13 @@
       csih_error "Problem with LocalSystem or Adminstrator IDs"
     fi
 
-    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
+    if [ `/usr/bin/stat -c '%g' ${LOCALSTATEDIR}` -eq \
+	 `/usr/bin/stat -c '%u' ${LOCALSTATEDIR}` ]
+    then
+      perms="d..x.....[xt]"
+    fi
+
+    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
     then
       csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
     fi

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

Hi Takashi,

On Sep 11 19:04, Takashi Yano wrote:
> Hi Corinna,
> 
> Regarding the first problem:
> > > a) Group permissions on root folders
> 
> On Sun, 6 Sep 2015 13:44:44 +0200
> Corinna Vinschen wrote:
> > The group permission problem is easy (and I'm wondering if it really was
> > such a bright idea to let user SID == group SID slip through in Cygwin,
> > rather tnan  sticking to the former idea to change the group SID to
> > "Users" in this case).  csih needs a patch to not check for the group
> > x bit if user SID == group SID.
> 
> Do you intend a patch like this? I have confirmed that sshd
> is successfully installed and works nicely with this patch
> under a Microsoft Account.
> 
> --- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
> +++ cygwin-service-installation-helper.sh	2015-09-11 18:41:56.870882800 +0900
> @@ -2442,6 +2442,8 @@
>  # ======================================================================
>  _csih_setup()
>  {
> +  local perms="d..x..x..[xt]"
> +
>    csih_stacktrace "${@}"
>    $_csih_trace
>    if [ "$_csih_setup_already_called" -eq 0 ]
> @@ -2462,7 +2464,13 @@
>        csih_error "Problem with LocalSystem or Adminstrator IDs"
>      fi
>  
> -    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
> +    if [ `/usr/bin/stat -c '%g' ${LOCALSTATEDIR}` -eq \
> +	 `/usr/bin/stat -c '%u' ${LOCALSTATEDIR}` ]
> +    then
> +      perms="d..x.....[xt]"
> +    fi
> +
> +    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
>      then
>        csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
>      fi

In theory, yes.  The problem is just that checking the uid/gid equality
is not safe, given that you can easily create that via passwd/group
files.  What I was thinking of is to convert the uid/gid values into
SIDs using the `getent' tool and to compare those, along the lines of

  uid=$(/usr/bin/stat -c '%u')
  user_sid=$(getent passwd -w $uid | awk -F: '{print $4}')
  gid=$(/usr/bin/stat -c '%g')
  grp_sid=$(getent group -w $gid | awk -F: '{print $4}')
  if [ "${user_sid}" = "${grp_sid}" ]
    ...

Can you check if that works in your env and perhaps create a new patch
using the SIDs?


Thanks a lot,
Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Takashi Yano]

Hi Corinna,

On Fri, 11 Sep 2015 13:10:12 +0200
Corinna Vinschen wrote:
> In theory, yes.  The problem is just that checking the uid/gid equality
> is not safe, given that you can easily create that via passwd/group
> files.  What I was thinking of is to convert the uid/gid values into
> SIDs using the `getent' tool and to compare those, along the lines of
> 
>   uid=$(/usr/bin/stat -c '%u')
>   user_sid=$(getent passwd -w $uid | awk -F: '{print $4}')
>   gid=$(/usr/bin/stat -c '%g')
>   grp_sid=$(getent group -w $gid | awk -F: '{print $4}')
>   if [ "${user_sid}" = "${grp_sid}" ]
>     ...
> 
> Can you check if that works in your env and perhaps create a new patch
> using the SIDs?

I have made a new patch and confirmed that it also works.


--- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
+++ cygwin-service-installation-helper.sh	2015-09-11 21:30:08.539361900 +0900
@@ -2442,6 +2442,12 @@
 # ======================================================================
 _csih_setup()
 {
+  local uid
+  local gid
+  local user_sid
+  local grp_sid
+  local perms="d..x..x..[xt]"
+
   csih_stacktrace "${@}"
   $_csih_trace
   if [ "$_csih_setup_already_called" -eq 0 ]
@@ -2462,7 +2468,17 @@
       csih_error "Problem with LocalSystem or Adminstrator IDs"
     fi
 
-    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
+    uid=$(/usr/bin/stat -c '%u' ${LOCALSTATEDIR})
+    gid=$(/usr/bin/stat -c '%g' ${LOCALSTATEDIR})
+    user_sid=$(/usr/bin/getent -w passwd $uid | awk -F: '{print $4}')
+    grp_sid=$(/usr/bin/getent -w group $gid | awk -F: '{print $4}')
+
+    if [ "${user_sid}" = "${grp_sid}" ]
+    then
+      perms="d..x.....[xt]"
+    fi
+
+    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
     then
       csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
     fi



-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

--
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: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Sep 11 21:33, Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 11 Sep 2015 13:10:12 +0200
> Corinna Vinschen wrote:
> > In theory, yes.  The problem is just that checking the uid/gid equality
> > is not safe, given that you can easily create that via passwd/group
> > files.  What I was thinking of is to convert the uid/gid values into
> > SIDs using the `getent' tool and to compare those, along the lines of
> > 
> >   uid=$(/usr/bin/stat -c '%u')
> >   user_sid=$(getent passwd -w $uid | awk -F: '{print $4}')
> >   gid=$(/usr/bin/stat -c '%g')
> >   grp_sid=$(getent group -w $gid | awk -F: '{print $4}')
> >   if [ "${user_sid}" = "${grp_sid}" ]
> >     ...
> > 
> > Can you check if that works in your env and perhaps create a new patch
> > using the SIDs?
> 
> I have made a new patch and confirmed that it also works.
> 
> 
> --- cygwin-service-installation-helper.sh.orig	2015-02-24 04:57:56.000000000 +0900
> +++ cygwin-service-installation-helper.sh	2015-09-11 21:30:08.539361900 +0900
> @@ -2442,6 +2442,12 @@
>  # ======================================================================
>  _csih_setup()
>  {
> +  local uid
> +  local gid
> +  local user_sid
> +  local grp_sid
> +  local perms="d..x..x..[xt]"
> +
>    csih_stacktrace "${@}"
>    $_csih_trace
>    if [ "$_csih_setup_already_called" -eq 0 ]
> @@ -2462,7 +2468,17 @@
>        csih_error "Problem with LocalSystem or Adminstrator IDs"
>      fi
>  
> -    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "d..x..x..[xt]"
> +    uid=$(/usr/bin/stat -c '%u' ${LOCALSTATEDIR})
> +    gid=$(/usr/bin/stat -c '%g' ${LOCALSTATEDIR})
> +    user_sid=$(/usr/bin/getent -w passwd $uid | awk -F: '{print $4}')
> +    grp_sid=$(/usr/bin/getent -w group $gid | awk -F: '{print $4}')
> +
> +    if [ "${user_sid}" = "${grp_sid}" ]
> +    then
> +      perms="d..x.....[xt]"
> +    fi
> +
> +    if ! csih_check_dir_perms "${LOCALSTATEDIR}" "${perms}"
>      then
>        csih_error "Problem with ${LOCALSTATEDIR} directory. Exiting."
>      fi

Thank you, patch applied.


Heading into vacation now.


Have fun,
Corinna

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

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

Re: Group Permissions on root folders problem (Windows 10 TP build 10061)

[Corinna Vinschen]

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

On Apr 29 10:45, Brian Buchanan wrote:
> I did a fresh cygwin-64 (setup-x86_64 version 2.870) install under
> build 10061 of Windows 10 Technical Preview.
> 
> The group permissions in the root look wrong.
> 
> $ ls -lA /
> total 321
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 bin
> dr-xr-xr-x  1 Brian Brian               0 Apr 29 10:31 cygdrive
> -rwxr-xr-x  1 Brian Administrators     59 Apr 29 10:31 Cygwin.bat
> -rw-r--r--  1 Brian Administrators 157097 Apr 29 10:31 Cygwin.ico
> -rw-r--r--  1 Brian Administrators  53342 Apr 29 10:31 Cygwin-Terminal.ico
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 dev
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 etc
> drwx---rwt+ 1 Brian Brian               0 Apr 29 10:31 home
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 lib
> dr-xr-xr-x  9 Brian Brian               0 Apr 29 10:31 proc
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 sbin
> drwx---rwt+ 1 Brian Brian               0 Apr 29 10:31 tmp
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:30 usr
> drwx---r-x+ 1 Brian Brian               0 Apr 29 10:30 var
> 
> I'm logged on with a Microsoft account and ran the installer as an
> Administrator.
> 
> This is a particular problem running ssh-host-config -y
> $ ssh-host-config -y
> 
> *** Info: Generating missing SSH host keys
> ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519
> *** Info: Creating default /etc/ssh_config file
> *** Info: Creating default /etc/sshd_config file
> 
> *** Info: StrictModes is set to 'yes' by default.
> *** Info: This is the recommended setting, but it requires that the POSIX
> *** Info: permissions of the user's home directory, the user's .ssh
> *** Info: directory, and the user's ssh key files are tight so that
> *** Info: only the user has write permissions.
> *** Info: On the other hand, StrictModes don't work well with default
> *** Info: Windows permissions of a home directory mounted with the
> *** Info: 'noacl' option, and they don't work at all if the home
> *** Info: directory is on a FAT or FAT32 partition.
> *** Query: Should StrictModes be used? (yes/no) yes
> 
> *** Info: Privilege separation is set to 'sandbox' by default since
> *** Info: OpenSSH 6.1.  This is unsupported by Cygwin and has to be set
> *** Info: to 'yes' or 'no'.
> *** Info: However, using privilege separation requires a non-privileged account
> *** Info: called 'sshd'.
> *** Info: For more info on privilege separation read
> /usr/share/doc/openssh/README.privsep.
> *** Query: Should privilege separation be used? (yes/no) yes
> *** Warning: The permissions on the directory /var are not correct.
> *** Warning: They must match the regexp d..x..x..[xt]
> *** ERROR: Problem with /var directory. Exiting.

Hmm, the permission test in the csih helper script is apparently not up
to the task in your situation.  As a workaround, you may want to change
the group ownership of /var/empty to "Users" and chmod it to 755, then
run the ssh-host-config script again.


Corinna

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

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

Group Permissions on root folders problem (Windows 10 TP build 10061)

[Brian Buchanan]

I did a fresh cygwin-64 (setup-x86_64 version 2.870) install under
build 10061 of Windows 10 Technical Preview.

The group permissions in the root look wrong.

$ ls -lA /
total 321
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 bin
dr-xr-xr-x  1 Brian Brian               0 Apr 29 10:31 cygdrive
-rwxr-xr-x  1 Brian Administrators     59 Apr 29 10:31 Cygwin.bat
-rw-r--r--  1 Brian Administrators 157097 Apr 29 10:31 Cygwin.ico
-rw-r--r--  1 Brian Administrators  53342 Apr 29 10:31 Cygwin-Terminal.ico
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 dev
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 etc
drwx---rwt+ 1 Brian Brian               0 Apr 29 10:31 home
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 lib
dr-xr-xr-x  9 Brian Brian               0 Apr 29 10:31 proc
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:31 sbin
drwx---rwt+ 1 Brian Brian               0 Apr 29 10:31 tmp
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:30 usr
drwx---r-x+ 1 Brian Brian               0 Apr 29 10:30 var

I'm logged on with a Microsoft account and ran the installer as an
Administrator.

This is a particular problem running ssh-host-config -y
$ ssh-host-config -y

*** Info: Generating missing SSH host keys
ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519
*** Info: Creating default /etc/ssh_config file
*** Info: Creating default /etc/sshd_config file

*** Info: StrictModes is set to 'yes' by default.
*** Info: This is the recommended setting, but it requires that the POSIX
*** Info: permissions of the user's home directory, the user's .ssh
*** Info: directory, and the user's ssh key files are tight so that
*** Info: only the user has write permissions.
*** Info: On the other hand, StrictModes don't work well with default
*** Info: Windows permissions of a home directory mounted with the
*** Info: 'noacl' option, and they don't work at all if the home
*** Info: directory is on a FAT or FAT32 partition.
*** Query: Should StrictModes be used? (yes/no) yes

*** Info: Privilege separation is set to 'sandbox' by default since
*** Info: OpenSSH 6.1.  This is unsupported by Cygwin and has to be set
*** Info: to 'yes' or 'no'.
*** Info: However, using privilege separation requires a non-privileged account
*** Info: called 'sshd'.
*** Info: For more info on privilege separation read
/usr/share/doc/openssh/README.privsep.
*** Query: Should privilege separation be used? (yes/no) yes
*** Warning: The permissions on the directory /var are not correct.
*** Warning: They must match the regexp d..x..x..[xt]
*** ERROR: Problem with /var directory. Exiting.

$ id
uid=197608(Brian) gid=197608(Brian) groups=197608(Brian),405504(High
Mandatory Level),114(Local account and member of Administrators
group),197611(HomeUsers),544(Administrators),545(Users),4(INTERACTIVE),66049(CONSOLE
LOGON),11(Authenticated Users),15(This
Organization),68521(MicrosoftAccount+brian@buchananworldcorp.com),113(Local
account),66048(LOCAL),262180(Cloud Account Authentication)

Am I doing something wrong?

Is there a way to fix the permissions or a workaround for installation?

Thanks,

Brian

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