Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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.0 +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-- 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)
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.orig2015-02-24 > 04:57:56.0 +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 pgp6tqUH4SIDl.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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.0 +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-- 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)
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.orig2015-02-24 > 04:57:56.0 +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 pgpsau6CgtDvu.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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.0 +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-- 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)
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.0 +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 pgp5iQIEBrdlW.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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.0 +0900 >> +++ cygwin-service-installation-helper.sh2015-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 signature.asc Description: OpenPGP digital signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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.orig2015-02-24 > 04:57:56.0 +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 pgpcbTc2O3Z64.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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 pgpTG9Sv8lZM7.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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. 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. 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)
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)
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 pgpZ0Poq6KlL6.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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 signature.asc Description: OpenPGP digital signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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)
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 signature.asc Description: OpenPGP digital signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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)
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/. 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: * 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... 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)
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 pgpKtMsMi7kVh.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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 > 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-- 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)
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)
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 pgpDjAvVOkP92.pgp Description: PGP signature
Re: Group Permissions on root folders problem (Windows 10 TP build 10061)
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 pgpc3VgMoW0cT.pgp Description: PGP signature