* [TESTERS needed] New POSIX permission handling @ 2015-04-10 10:07 Corinna Vinschen 2015-04-10 21:13 ` Warren Young ` (3 more replies) 0 siblings, 4 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-10 10:07 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2734 bytes --] Hi folks, I just applied a patch I'm working on for quite some time now. As I outlined before on this list, the POSIX permission handling has aged considerably and, for historical reasons, did things differently dependent on the calling function. I took the time to reimplement the core functionality to handle all ACLs as strictly following POSIX ACL rules as possible. Cygwin now generates ACLs in a certain way, always following the same construction rules. The new ACLs are always recognizable as Cygwin ACLs. The always start with an Access-Denied ACE for the NULL SID with certain bits set. Any ACL not starting this way is handled as a non-Cygwin or "old style" ACL, but still trying to evaluate the ACL as strictly following POSIX rules as possible. Two other noticable changes from before: - To accommodate Windows default ACLs, the new code ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. That means, even if SYSTEM or Administrators have full access to the file, the POSIX permssion bits will not reflect that fact. And while other users get access denied based on the mask value, SYSTEM and Administrators will never get access denied based on the mask. This should help in Cygwin<->Windows interoperability. - The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. But note that this only works for files and directories created by Cygwin processes. The group change is not supported automagically by Windows, so the process creating the new file has to change the file group silenmtly after creating the file. Apart from bugfixing the aforementioned code, there's still work to do on the getfacl and setfacl tools: - The getfacl tool needs an extension in output to print the effective permissions on users and groups restricted by the mask value. - The setfacl tool needs code to compute the new mask value, just as on Linux. I'm looking into that next week. Please give the new code a try. I uploaded new 2015-04-10 developer snapshots to https://cygwin.com/snapshots/ Probably next week I will also create a test release which can be installed via setup-x86{_64}.exe. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-10 10:07 [TESTERS needed] New POSIX permission handling Corinna Vinschen @ 2015-04-10 21:13 ` Warren Young 2015-04-11 9:35 ` Corinna Vinschen 2015-04-11 0:00 ` Steven Penny ` (2 subsequent siblings) 3 siblings, 1 reply; 42+ messages in thread From: Warren Young @ 2015-04-10 21:13 UTC (permalink / raw) To: cygwin On Apr 10, 2015, at 4:07 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: > > This should help in Cygwin<->Windows interoperability. That’s pretty vague. Would you care to list some specific expected improvements from this change? Are there known problem scenarios in the current world which we can test both ways, which should behave differently under the new DLL? For instance, does it fix the well-known problem with chmod 600 ~/.ssh/* resulting in mode 660 until you kick the ACLs around a bit? -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-10 21:13 ` Warren Young @ 2015-04-11 9:35 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 9:35 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 961 bytes --] On Apr 10 15:13, Warren Young wrote: > On Apr 10, 2015, at 4:07 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: > > > > This should help in Cygwin<->Windows interoperability. > > That’s pretty vague. > > Would you care to list some specific expected improvements from this > change? Are there known problem scenarios in the current world which > we can test both ways, which should behave differently under the new > DLL? > > For instance, does it fix the well-known problem with chmod 600 > ~/.ssh/* resulting in mode 660 until you kick the ACLs around a bit? Yes. This has been discussed and I was originally opposing this change, but not very loudly. Other than that, please read the archives. You'll find the threads discussing this in the last two months. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-10 10:07 [TESTERS needed] New POSIX permission handling Corinna Vinschen 2015-04-10 21:13 ` Warren Young @ 2015-04-11 0:00 ` Steven Penny 2015-04-11 9:40 ` Corinna Vinschen 2015-05-16 2:39 ` Steven Penny 2015-04-11 8:47 ` Achim Gratz 2015-04-11 17:11 ` donmez 3 siblings, 2 replies; 42+ messages in thread From: Steven Penny @ 2015-04-11 0:00 UTC (permalink / raw) To: cygwin On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote: > Please give the new code a try. I uploaded new 2015-04-10 developer > snapshots to https://cygwin.com/snapshots/ Here is the test I ran: $ cd /cygdrive/c $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh $ chmod +x ~/bravo.sh ~+/delta.sh $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh (green) -rw-r--r-- 1 John None 0 Apr 10 16:51 /home/John/alpha.sh -rwxrwxr-x 1 John None 0 Apr 10 16:51 /home/John/bravo.sh (green) So "charlie.sh" looks strange because it has that extra write permission. However this is not a big deal for me. My concern was that everything was showing up executable (green) when running "ls --color". So overall this is an improvement, thanks. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 0:00 ` Steven Penny @ 2015-04-11 9:40 ` Corinna Vinschen 2015-04-11 10:07 ` Corinna Vinschen ` (2 more replies) 2015-05-16 2:39 ` Steven Penny 1 sibling, 3 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 9:40 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1491 bytes --] On Apr 10 19:00, Steven Penny wrote: > On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote: > > Please give the new code a try. I uploaded new 2015-04-10 developer > > snapshots to https://cygwin.com/snapshots/ > > Here is the test I ran: > > $ cd /cygdrive/c > > $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > > $ chmod +x ~/bravo.sh ~+/delta.sh > > $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh > -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh (green) > -rw-r--r-- 1 John None 0 Apr 10 16:51 /home/John/alpha.sh > -rwxrwxr-x 1 John None 0 Apr 10 16:51 /home/John/bravo.sh (green) > > So "charlie.sh" looks strange because it has that extra write permission. > However this is not a big deal for me. My concern was that everything was > showing up executable (green) when running "ls --color". So overall this is an > improvement, thanks. What is '~+'? Is that some weird bash feature? Did you check the ACL? The ACL before and after the change should explain what happened. Check it with getfacl *and* icacls to get an idea what it looks like, and compare the result with the POSIX ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:40 ` Corinna Vinschen @ 2015-04-11 10:07 ` Corinna Vinschen 2015-04-11 16:26 ` Ernie Rael 2015-04-11 10:23 ` Corinna Vinschen 2015-04-11 10:47 ` Steven Penny 2 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 10:07 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2543 bytes --] On Apr 11 11:40, Corinna Vinschen wrote: > On Apr 10 19:00, Steven Penny wrote: > > On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote: > > > Please give the new code a try. I uploaded new 2015-04-10 developer > > > snapshots to https://cygwin.com/snapshots/ > > > > Here is the test I ran: > > > > $ cd /cygdrive/c > > > > $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > > > > $ chmod +x ~/bravo.sh ~+/delta.sh > > > > $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > > -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh > > -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh (green) > > -rw-r--r-- 1 John None 0 Apr 10 16:51 /home/John/alpha.sh > > -rwxrwxr-x 1 John None 0 Apr 10 16:51 /home/John/bravo.sh (green) > > > > So "charlie.sh" looks strange because it has that extra write permission. > > However this is not a big deal for me. My concern was that everything was > > showing up executable (green) when running "ls --color". So overall this is an > > improvement, thanks. > > What is '~+'? Is that some weird bash feature? > > Did you check the ACL? The ACL before and after the change should > explain what happened. Check it with getfacl *and* icacls to get > an idea what it looks like, and compare the result with the POSIX > ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl. On second thought, what you need to know is what the NULL DENY ACE looks like when looking at it in icacls. The following bits in the NULL DENY access mask are used: Windows access <-> POSIX access -------------- ------------ FILE_READ_DATA S_ISVTX FILE_WRITE_DATA S_ISGID FILE_APPEND_DATA S_ISUID FILE_READ_EA MASK S_IXOTH (POSIX execute perms) FILE_WRITE_EA MASK S_IWOTH (POSIX write perms) FILE_EXECUTE MASK S_IROTH (POSIX read perms) FILE_DELETE_CHILD Set if MASK is valid READ_CONTROL Set to mark this as a "new style" ACL. SYNCHRONIZE Has no meaning, but icacls has a bug in printing the access mask of DENY ACEs. Same bits are used in the inheritable NULL DENY, but S_ISVTX and S_ISUID should never be set, because they are not supposed to be inherited, HTH, 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 10:07 ` Corinna Vinschen @ 2015-04-11 16:26 ` Ernie Rael 2015-04-12 8:22 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Ernie Rael @ 2015-04-11 16:26 UTC (permalink / raw) To: cygwin I'm primarily a lurker, reading this list hoping things soak in a bit. So I may be off base on this. In the table below, describing "NULL DENY access mask", looks like there's a typo concerning read/execute. (of course it might just be a windows mapping peculiarity that I really didn't want to know about ;-) -ernie On 4/11/2015 3:07 AM, Corinna Vinschen wrote: > On Apr 11 11:40, Corinna Vinschen wrote: >> On Apr 10 19:00, Steven Penny wrote: >>> On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote: >>>> Please give the new code a try. I uploaded new 2015-04-10 developer >>>> snapshots to https://cygwin.com/snapshots/ >>> Here is the test I ran: >>> >>> $ cd /cygdrive/c >>> >>> $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh >>> >>> $ chmod +x ~/bravo.sh ~+/delta.sh >>> >>> $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh >>> -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh >>> -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh (green) >>> -rw-r--r-- 1 John None 0 Apr 10 16:51 /home/John/alpha.sh >>> -rwxrwxr-x 1 John None 0 Apr 10 16:51 /home/John/bravo.sh (green) >>> >>> So "charlie.sh" looks strange because it has that extra write permission. >>> However this is not a big deal for me. My concern was that everything was >>> showing up executable (green) when running "ls --color". So overall this is an >>> improvement, thanks. >> What is '~+'? Is that some weird bash feature? >> >> Did you check the ACL? The ACL before and after the change should >> explain what happened. Check it with getfacl *and* icacls to get >> an idea what it looks like, and compare the result with the POSIX >> ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl. > On second thought, what you need to know is what the NULL DENY ACE looks > like when looking at it in icacls. > > The following bits in the NULL DENY access mask are used: > > Windows access <-> POSIX access > -------------- ------------ > FILE_READ_DATA S_ISVTX > FILE_WRITE_DATA S_ISGID > FILE_APPEND_DATA S_ISUID > > FILE_READ_EA MASK S_IXOTH (POSIX execute perms) > FILE_WRITE_EA MASK S_IWOTH (POSIX write perms) > FILE_EXECUTE MASK S_IROTH (POSIX read perms) Are read and execute swapped intentionally in the above? > > FILE_DELETE_CHILD Set if MASK is valid > > READ_CONTROL Set to mark this as a "new style" ACL. > > SYNCHRONIZE Has no meaning, but icacls has a bug in > printing the access mask of DENY ACEs. > > Same bits are used in the inheritable NULL DENY, but S_ISVTX and S_ISUID > should never be set, because they are not supposed to be inherited, > > > HTH, > Corinna > -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 16:26 ` Ernie Rael @ 2015-04-12 8:22 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-12 8:22 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1704 bytes --] On Apr 11 09:26, Ernie Rael wrote: > I'm primarily a lurker, reading this list hoping things soak in a bit. So I > may be off base on this. > > In the table below, describing "NULL DENY access mask", looks like there's a > typo concerning read/execute. (of course it might just be a windows mapping > peculiarity that I really didn't want to know about ;-) Hey, cool, somebody noticed :) And since you asked, you'll get to know, whether you want or not ;) > >The following bits in the NULL DENY access mask are used: > > > > Windows access <-> POSIX access > > -------------- ------------ > > FILE_READ_DATA S_ISVTX > > FILE_WRITE_DATA S_ISGID > > FILE_APPEND_DATA S_ISUID > > > > FILE_READ_EA MASK S_IXOTH (POSIX execute perms) > > FILE_WRITE_EA MASK S_IWOTH (POSIX write perms) > > FILE_EXECUTE MASK S_IROTH (POSIX read perms) > > Are read and execute swapped intentionally in the above? Yes, indeed. since the NULL access mask is not needed for actual permission checking by Windows, we can use the bit as they fit our needs. The reason for using them in this order are their bit values. FILE_READ_EA == 0x08 S_IXOTH == 0x01 FILE_WRITE_EA == 0x10 S_IWOTH == 0x02 FILE_EXECUTE == 0x20 S_IROTH == 0x04 To convert from Windows to POSIX and vice versa, a simple shift operation is sufficient. Reordering just to fit the symbolic name would complicate the conversion unnecessarily. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:40 ` Corinna Vinschen 2015-04-11 10:07 ` Corinna Vinschen @ 2015-04-11 10:23 ` Corinna Vinschen 2015-04-11 10:47 ` Steven Penny 2 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 10:23 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1991 bytes --] On Apr 11 11:40, Corinna Vinschen wrote: > On Apr 10 19:00, Steven Penny wrote: > > On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote: > > > Please give the new code a try. I uploaded new 2015-04-10 developer > > > snapshots to https://cygwin.com/snapshots/ > > > > Here is the test I ran: > > > > $ cd /cygdrive/c > > > > $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > > > > $ chmod +x ~/bravo.sh ~+/delta.sh > > > > $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > > -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh > > -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh (green) > > -rw-r--r-- 1 John None 0 Apr 10 16:51 /home/John/alpha.sh > > -rwxrwxr-x 1 John None 0 Apr 10 16:51 /home/John/bravo.sh (green) > > > > So "charlie.sh" looks strange because it has that extra write permission. > > However this is not a big deal for me. My concern was that everything was > > showing up executable (green) when running "ls --color". So overall this is an > > improvement, thanks. > > What is '~+'? Is that some weird bash feature? > > Did you check the ACL? The ACL before and after the change should > explain what happened. Oh, sorry, you're createsing new files, so there's no before/after. In that case the result in the group permission is based on the MASK value generated as a result of permission inhertance rules. So what you should check is the parent descriptor and look at the inheritable ACEs (default ACL entries in POSIX speak) and compare them with the permissions Xof the newly created files. > Check it with getfacl *and* icacls to get > an idea what it looks like, and compare the result with the POSIX > ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:40 ` Corinna Vinschen 2015-04-11 10:07 ` Corinna Vinschen 2015-04-11 10:23 ` Corinna Vinschen @ 2015-04-11 10:47 ` Steven Penny 2015-04-11 14:30 ` Corinna Vinschen 2015-04-11 16:05 ` Andrey Repin 2 siblings, 2 replies; 42+ messages in thread From: Steven Penny @ 2015-04-11 10:47 UTC (permalink / raw) To: cygwin On Sat, Apr 11, 2015 at 4:40 AM, Corinna Vinschen wrote: > What is '~+'? Is that some weird bash feature? If the tilde-prefix is ‘~+’, the value of the shell variable PWD replaces the tilde-prefix. http://gnu.org/software/bash/manual/html_node/Tilde-Expansion -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 10:47 ` Steven Penny @ 2015-04-11 14:30 ` Corinna Vinschen 2015-04-11 16:05 ` Andrey Repin 1 sibling, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 14:30 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 483 bytes --] On Apr 11 05:47, Steven Penny wrote: > On Sat, Apr 11, 2015 at 4:40 AM, Corinna Vinschen wrote: > > What is '~+'? Is that some weird bash feature? > > If the tilde-prefix is ‘~+’, the value of the shell variable PWD replaces the > tilde-prefix. Ah, thanks. Learn something new each day (tcsh user here). 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 10:47 ` Steven Penny 2015-04-11 14:30 ` Corinna Vinschen @ 2015-04-11 16:05 ` Andrey Repin 2015-04-12 17:37 ` Adam Dinwoodie 1 sibling, 1 reply; 42+ messages in thread From: Andrey Repin @ 2015-04-11 16:05 UTC (permalink / raw) To: Steven Penny, cygwin Greetings, Steven Penny! >> What is '~+'? Is that some weird bash feature? > If the tilde-prefix is ‘~+’, the value of the shell variable PWD replaces the > tilde-prefix. > http://gnu.org/software/bash/manual/html_node/Tilde-Expansion In other words, "~+/" is a weird way to say "./" ? -- With best regards, Andrey Repin Saturday, April 11, 2015 18:57:50 Sorry for my terrible english... ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 16:05 ` Andrey Repin @ 2015-04-12 17:37 ` Adam Dinwoodie 0 siblings, 0 replies; 42+ messages in thread From: Adam Dinwoodie @ 2015-04-12 17:37 UTC (permalink / raw) To: cygwin On 11/04/2015 16:58, Andrey Repin wrote: > Greetings, Steven Penny! > >>> What is '~+'? Is that some weird bash feature? > >> If the tilde-prefix is â~+â, the value of the shell variable PWD >> replaces the tilde-prefix. > >> http://gnu.org/software/bash/manual/html_node/Tilde-Expansion > > In other words, "~+/" is a weird way to say "./" ? Strictly, no: `echo ./` will print `./`, while `echo ~+/` will print the absolute current path, the same as `echo "$PWD"/` would. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 0:00 ` Steven Penny 2015-04-11 9:40 ` Corinna Vinschen @ 2015-05-16 2:39 ` Steven Penny 2015-05-17 7:44 ` Duncan Roe 2015-05-19 7:52 ` Jiří Engelthaler 1 sibling, 2 replies; 42+ messages in thread From: Steven Penny @ 2015-05-16 2:39 UTC (permalink / raw) To: cygwin On Fri, Apr 10, 2015 at 7:00 PM, Steven Penny wrote: > Here is the test I ran: The test I ran here http://cygwin.com/ml/cygwin/2015-04/msg00186.html is now failing again: $ cd /cygdrive/c $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh $ chmod +x ~/bravo.sh ~+/delta.sh $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh -rw-rwxr--+ 1 John None 0 May 15 19:12 /cygdrive/c/charlie.sh (green) -rwxrwxr-x+ 1 John None 0 May 15 19:12 /cygdrive/c/delta.sh (green) -rw-r--r-- 1 John None 0 May 15 19:12 /home/John/alpha.sh -rwxr-xr-x 1 John None 0 May 15 19:12 /home/John/bravo.sh (green) Please sort this out. Having ‘ls --color’ is pointless if everything is the same color. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-05-16 2:39 ` Steven Penny @ 2015-05-17 7:44 ` Duncan Roe 2015-05-19 7:52 ` Jiří Engelthaler 1 sibling, 0 replies; 42+ messages in thread From: Duncan Roe @ 2015-05-17 7:44 UTC (permalink / raw) To: cygwin On Fri, May 15, 2015 at 09:20:10PM -0500, Steven Penny wrote: > On Fri, Apr 10, 2015 at 7:00 PM, Steven Penny wrote: > > Here is the test I ran: > > The test I ran here > http://cygwin.com/ml/cygwin/2015-04/msg00186.html > is now failing again: > > $ cd /cygdrive/c > > $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > > $ chmod +x ~/bravo.sh ~+/delta.sh > > $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh > -rw-rwxr--+ 1 John None 0 May 15 19:12 /cygdrive/c/charlie.sh (green) > -rwxrwxr-x+ 1 John None 0 May 15 19:12 /cygdrive/c/delta.sh (green) > -rw-r--r-- 1 John None 0 May 15 19:12 /home/John/alpha.sh > -rwxr-xr-x 1 John None 0 May 15 19:12 /home/John/bravo.sh (green) > > Please sort this out. Having ???ls --color??? is pointless if everything is the same > color. > Your results look fine to me. In your original test, charlie.sh was -rw-rw-r--+, but now it is -rw-rwxr--+ (i.e. it has acquired group execute access). So why would you not expect it to show in green? Cheers ... Duncan. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-05-16 2:39 ` Steven Penny 2015-05-17 7:44 ` Duncan Roe @ 2015-05-19 7:52 ` Jiří Engelthaler 1 sibling, 0 replies; 42+ messages in thread From: Jiří Engelthaler @ 2015-05-19 7:52 UTC (permalink / raw) To: cygwin Here https://www.cygwin.com/ml/cygwin/2015-05/msg00139.html is another posix permission related problem. Without answer from authors. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-10 10:07 [TESTERS needed] New POSIX permission handling Corinna Vinschen 2015-04-10 21:13 ` Warren Young 2015-04-11 0:00 ` Steven Penny @ 2015-04-11 8:47 ` Achim Gratz 2015-04-11 9:02 ` David Macek ` (2 more replies) 2015-04-11 17:11 ` donmez 3 siblings, 3 replies; 42+ messages in thread From: Achim Gratz @ 2015-04-11 8:47 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > - To accommodate Windows default ACLs, the new code ignores SYSTEM and > Administrators group permissions when computing the MASK/CLASS_OBJ > permission mask on old ACLs, and it doesn't deny access to SYSTEM and > Administrators group based on the value of MASK/CLASS_OBJ when > creating the new ACLs. Since you've now opened that can of worms of who is considered "root", what about "Domain Administrators" or "Power Users", for starters? > That means, even if SYSTEM or Administrators have full access to the > file, the POSIX permssion bits will not reflect that fact. And while > other users get access denied based on the mask value, SYSTEM and > Administrators will never get access denied based on the mask. If you want to put this to better use in larger settings it would seem preferrable if it was possible to define a list of users to treat this way in fstab. I think this would help with the braindead settings NetApp filers are set up these days by default. That generally means that some domain group(s) need to be considered root on the share depending on which share you are accessing. > Apart from bugfixing the aforementioned code, there's still work to do > on the getfacl and setfacl tools: Sorry to pile another one on here: Currently it's not possible to use -k and -b on the same invocation. This works just fine on Linux. Having the newer getfacl / setfacl from *BSD that deals with NFSv4 ACL might be worth a shot, since at least superficially these seem to match better to NTFS DACL in scope and would probably bring it more in line with what icacls would show and do. Before you ask, it has been duly noted that NFSv4 ACL are somewhat incompatible with POSIX ACL in the same way that NTFS DACL are… maybe some more info can be gleaned from those documents: http://users.suse.com/~agruen/acl/linux-acls/online/ http://users.suse.com/~agruen/nfs4acl/ http://www.ietf.org/archive/id/draft-ietf-nfsv4-acl-mapping-03.txt http://www.bestbits.at/richacl/draft-gruenbacher-nfsv4-acls-in-posix-00.html http://docs.oracle.com/cd/E23824_01/html/821-1448/gbacb.html Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 8:47 ` Achim Gratz @ 2015-04-11 9:02 ` David Macek 2015-04-11 9:08 ` Achim Gratz 2015-04-11 10:00 ` Corinna Vinschen 2015-04-11 9:44 ` Corinna Vinschen 2015-04-11 16:05 ` Andrey Repin 2 siblings, 2 replies; 42+ messages in thread From: David Macek @ 2015-04-11 9:02 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1714 bytes --] On 11. 4. 2015 10:47, Achim Gratz wrote: > Corinna Vinschen writes: >> - To accommodate Windows default ACLs, the new code ignores SYSTEM and >> Administrators group permissions when computing the MASK/CLASS_OBJ >> permission mask on old ACLs, and it doesn't deny access to SYSTEM and >> Administrators group based on the value of MASK/CLASS_OBJ when >> creating the new ACLs. Out of curiosity, does the code somehow distinguish ACLs that don't have these default permissions (or have different permissions set for SYSTEM / Administrators)? > Since you've now opened that can of worms of who is considered "root", > what about "Domain Administrators" or "Power Users", for starters? > >> That means, even if SYSTEM or Administrators have full access to the >> file, the POSIX permssion bits will not reflect that fact. And while >> other users get access denied based on the mask value, SYSTEM and >> Administrators will never get access denied based on the mask. > > If you want to put this to better use in larger settings it would seem > preferrable if it was possible to define a list of users to treat this > way in fstab. I think this would help with the braindead settings > NetApp filers are set up these days by default. That generally means > that some domain group(s) need to be considered root on the share > depending on which share you are accessing. Power Users don't have access to (almost) everything, like Administrators do. The Domain Administrators group is a member of Administrators, so unless I'm missing something, there's no reason to have them explicitely in the DACL. I'm not arguing against configurability though. -- David Macek [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4234 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:02 ` David Macek @ 2015-04-11 9:08 ` Achim Gratz 2015-04-11 9:51 ` David Macek 2015-04-11 10:00 ` Corinna Vinschen 1 sibling, 1 reply; 42+ messages in thread From: Achim Gratz @ 2015-04-11 9:08 UTC (permalink / raw) To: cygwin David Macek writes: > Power Users don't have access to (almost) everything, like > Administrators do. The Domain Administrators group is a member of > Administrators, so unless I'm missing something, there's no reason to > have them explicitely in the DACL. That doesn't stop folks from using them in DACL entries and membership of one group in another (rightly) doesn't confer transitive access rights. I've just named these two examples because I've seen them before in ACL, I make no claim as to whether that's a sensible thing to do or not. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:08 ` Achim Gratz @ 2015-04-11 9:51 ` David Macek 2015-04-11 11:51 ` Achim Gratz 0 siblings, 1 reply; 42+ messages in thread From: David Macek @ 2015-04-11 9:51 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1663 bytes --] On 11. 4. 2015 11:08, Achim Gratz wrote: > David Macek writes: >> Power Users don't have access to (almost) everything, like >> Administrators do. The Domain Administrators group is a member of >> Administrators, so unless I'm missing something, there's no reason to >> have them explicitely in the DACL. > > That doesn't stop folks from using them in DACL entries and membership > of one group in another (rightly) doesn't confer transitive access > rights. I've just named these two examples because I've seen them > before in ACL, I make no claim as to whether that's a sensible thing to > do or not. https://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx says otherwise about the group-in-group rights. I'm a bit confused. Maybe we're talking about different things -- of course it makes sense to give Domain Administrators more rights than Administrators, but I don't see any reason for blanket granting Domain Administrators explicit rights on everything on the filesystem. The way I see it, the point of the code change was to prevent the "implicit" Administrators and SYSTEM DACL entries from showing up in the computed POSIX access mask because they nicely match the implicit rights root accounts have on POSIX systems and because they're unhelpful and sometimes problematic. As neither Domain Administrators nor Power Users have this combination of properties (presence on most filesystem objects by default and SeTakeOwnershipPrivilege), I think it's useful to have them appear in the mask. Please correct me if I'm talking nonsense; I have little practical experience with domain environments. -- David Macek [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4234 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:51 ` David Macek @ 2015-04-11 11:51 ` Achim Gratz 0 siblings, 0 replies; 42+ messages in thread From: Achim Gratz @ 2015-04-11 11:51 UTC (permalink / raw) To: cygwin David Macek writes: > https://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx > says otherwise about the group-in-group rights. As I see it, nesting groups is just a more efficient way of populating them, so by expanding the nested groups recursively you'll end up with the effective set of users that have those rights. But if I have a DACL permission for "Domain Admins" that still doesn't mean that "Administrators" (the group) gets access. The other way around (intentionally) works, by virtue of "Domain Admins" being a member of "Administrators". Also, "Administrator" (the account) is by default a member of both "Administrators" and "Domain Administrators", which is a bit confusing. > The way I see it, the point of the code change was to prevent the > "implicit" Administrators and SYSTEM DACL entries from showing up in > the computed POSIX access mask because they nicely match the implicit > rights root accounts have on POSIX systems and because they're > unhelpful and sometimes problematic. My point is that the interpretation of who gets to call himself "root" in that analogy is quite fuzzy and sometimes depends on the filesystem you look at. The choice proffered by Cygwin now is mostly correct for local file systems, but not necessarily for network shares (and most certainly not for a few important ones I'll have to deal with). The fallback will be to mount with "noacl" as before, something I had hoped would no longer be necessary. I have a few applications where the faked file modes simply don't cut it and so far I've been lucky that either the shares these need to be on are configured differently by default (like my home "drive") or I could convince IT to give me something non-standard. But the next round of filer or server upgrades or changed security policies might leave me stranded, so I'm really not too keen to rely on that indefinitely. > As neither Domain Administrators nor Power Users have this combination > of properties (presence on most filesystem objects by default and > SeTakeOwnershipPrivilege), I think it's useful to have them appear in > the mask. For isolated systems and small networks, this is wholly sufficient. Large networked installations have, for better or worse, more complicated setups. Again, I see a lot of cruft that likely wouldn't be necessary and is probably largely historical, but some of it really can't be changed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:02 ` David Macek 2015-04-11 9:08 ` Achim Gratz @ 2015-04-11 10:00 ` Corinna Vinschen 2015-04-11 12:36 ` David Macek 1 sibling, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 10:00 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2895 bytes --] On Apr 11 11:01, David Macek wrote: > On 11. 4. 2015 10:47, Achim Gratz wrote: > > Corinna Vinschen writes: > >> - To accommodate Windows default ACLs, the new code ignores SYSTEM and > >> Administrators group permissions when computing the MASK/CLASS_OBJ > >> permission mask on old ACLs, and it doesn't deny access to SYSTEM and > >> Administrators group based on the value of MASK/CLASS_OBJ when > >> creating the new ACLs. > > Out of curiosity, does the code somehow distinguish ACLs that don't > have these default permissions (or have different permissions set for > SYSTEM / Administrators)? I don't quite understand the question. For a start, I'd like to point out how POSIX ACLs are supposed to work. http://linux.die.net/man/5/acl is a good start. This is our role model. What this new code in Cygwin does is to ignore SYSTEM and Administrators account in a very specific way: It ignores both accounts in terms of the MASK (or CLASS_OBJ in Solaris speak) values in both directions: - The "new style" ACLs contain an explicit MASK/CLASS_OBJ value. If the MASK/CLASS_OBJ value only allows rw- permissions, but a secondary user or group account has rwx permissions, Cygwin will generate an --x DENY ACE for this group. The exception here: It won't generate this DENY for SYSTEM and Administrators. So even if MASK disallows certain access, SYSTEM and Administrators are not affected but get their full set of permssions granted by the user or inheritance rules. - The "old style" ACLs (created by native Windows means or by former Cygwin versions) don't have an explicit MASK. The new Cygwin code generates a MASK value on the fly while reading the ACL. This mask value is refelected by the group permission bits in the POSIX permission mask. Since SYSTEM and Administrators often have "Full Access" to any object on the filesystem, that means that very often, the group permissions are "rwx", because the MASK value is "rwx". The new code will compute the mask the same way as before, but it skips the permissions of SYSTEM and Administrators while doing that. That means, the POSIX group permission bits are not affected by the Windows-typical permissions of SYSTEM and Administrators. Example: User rw- Primary group r-- Other user rw- Other group r-- SYSTEM rwx Everyone --- The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum of all group and secondary user permissions rw- | r-- | rwx == rwx The new code ignores SYSTEM, thus the mask is rw- | r-- == rw- Does this explain it sufficiently? 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 10:00 ` Corinna Vinschen @ 2015-04-11 12:36 ` David Macek 2015-04-11 14:31 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: David Macek @ 2015-04-11 12:36 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1485 bytes --] On 11. 4. 2015 11:59, Corinna Vinschen wrote: >> Out of curiosity, does the code somehow distinguish ACLs that don't >> have these default permissions (or have different permissions set for >> SYSTEM / Administrators)? > > I don't quite understand the question. > > For a start, I'd like to point out how POSIX ACLs are supposed to work. > http://linux.die.net/man/5/acl is a good start. This is our role model. I'm gonna read that. > The new code will compute the mask the same way as before, but it > skips the permissions of SYSTEM and Administrators while doing that. > That means, the POSIX group permission bits are not affected by > the Windows-typical permissions of SYSTEM and Administrators. > > Example: > > User rw- > Primary group r-- > Other user rw- > Other group r-- > SYSTEM rwx > Everyone --- > > The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum > of all group and secondary user permissions > > rw- | r-- | rwx == rwx > > The new code ignores SYSTEM, thus the mask is > > rw- | r-- == rw- > > Does this explain it sufficiently? Yes, thank you. My question was about the case where SYSTEM or Administrator doesn't have the typical permissions. From this explanation, I assume that I won't be able to see any difference in the mask in that case, but it doesn't seem to be a bad thing. -- David Macek [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4234 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 12:36 ` David Macek @ 2015-04-11 14:31 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 14:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1776 bytes --] On Apr 11 14:35, David Macek wrote: > On 11. 4. 2015 11:59, Corinna Vinschen wrote: > >> Out of curiosity, does the code somehow distinguish ACLs that don't > >> have these default permissions (or have different permissions set for > >> SYSTEM / Administrators)? > > > > I don't quite understand the question. > > > > For a start, I'd like to point out how POSIX ACLs are supposed to work. > > http://linux.die.net/man/5/acl is a good start. This is our role model. > > I'm gonna read that. > > > The new code will compute the mask the same way as before, but it > > skips the permissions of SYSTEM and Administrators while doing that. > > That means, the POSIX group permission bits are not affected by > > the Windows-typical permissions of SYSTEM and Administrators. > > > > Example: > > > > User rw- > > Primary group r-- > > Other user rw- > > Other group r-- > > SYSTEM rwx > > Everyone --- > > > > The computed POSIX MASK/CLASS_OBJ value in Cygwin 1.7.35 is the sum > > of all group and secondary user permissions > > > > rw- | r-- | rwx == rwx > > > > The new code ignores SYSTEM, thus the mask is > > > > rw- | r-- == rw- > > > > Does this explain it sufficiently? > > Yes, thank you. My question was about the case where SYSTEM or > Administrator doesn't have the typical permissions. From this > explanation, I assume that I won't be able to see any difference in > the mask in that case, but it doesn't seem to be a bad thing. I'm seriously hoping so. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 8:47 ` Achim Gratz 2015-04-11 9:02 ` David Macek @ 2015-04-11 9:44 ` Corinna Vinschen 2015-04-11 11:11 ` Bryan Berns 2015-04-11 16:05 ` Andrey Repin 2 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 9:44 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1987 bytes --] On Apr 11 10:47, Achim Gratz wrote: > Corinna Vinschen writes: > > - To accommodate Windows default ACLs, the new code ignores SYSTEM and > > Administrators group permissions when computing the MASK/CLASS_OBJ > > permission mask on old ACLs, and it doesn't deny access to SYSTEM and > > Administrators group based on the value of MASK/CLASS_OBJ when > > creating the new ACLs. > > Since you've now opened that can of worms of who is considered "root", > what about "Domain Administrators" or "Power Users", for starters? Nope. The special handling for SYSTEM and Admins will help for the default permission settings on Windows filesystems, and it won't negatively influence the ACL mask handling. > > That means, even if SYSTEM or Administrators have full access to the > > file, the POSIX permssion bits will not reflect that fact. And while > > other users get access denied based on the mask value, SYSTEM and > > Administrators will never get access denied based on the mask. > > If you want to put this to better use in larger settings it would seem > preferrable if it was possible to define a list of users to treat this > way in fstab. Nope, sorry, no configuration for this. Either it's handled without any exception, or for SYSTEM only, or for SYSTEM+Admins. But either way, we're doing it the same way on every system. > Sorry to pile another one on here: Currently it's not possible to use -k > and -b on the same invocation. This works just fine on Linux. I'm not planning to work on this, but as for other parts of Cygwin, I do take patches. > Having the newer getfacl / setfacl from *BSD that deals with NFSv4 ACL > might be worth a shot, ACL handling on Cygwin is POSIX ACL handling. Either that or you set "noacl" and use Windows tools. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 9:44 ` Corinna Vinschen @ 2015-04-11 11:11 ` Bryan Berns 2015-04-11 14:32 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Bryan Berns @ 2015-04-11 11:11 UTC (permalink / raw) To: cygwin >> > That means, even if SYSTEM or Administrators have full access to the >> > file, the POSIX permssion bits will not reflect that fact. And while >> > other users get access denied based on the mask value, SYSTEM and >> > Administrators will never get access denied based on the mask. >> >> If you want to put this to better use in larger settings it would seem >> preferrable if it was possible to define a list of users to treat this >> way in fstab. > > Nope, sorry, no configuration for this. Either it's handled without > any exception, or for SYSTEM only, or for SYSTEM+Admins. But either > way, we're doing it the same way on every system. Damn. I was about to reply with Achim's exact same thought --- like a file in /etc with a list of SIDs. I can empathize with Corinna's veto though -- having a hundred tweak-able settings in Cygwin is unmaintainable for the general populous. I may apply a local patch to extend this ability myself because Cygwin has become rather unusable for users with home's on our network drives (given all the programs that attempt to do sanity checks on group perms). That said, I appreciate what has been integrated --- it will help in several scenarios. I will test the release this weekend. Thanks for all the hard work! -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 11:11 ` Bryan Berns @ 2015-04-11 14:32 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-11 14:32 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1669 bytes --] On Apr 11 07:11, Bryan Berns wrote: > >> > That means, even if SYSTEM or Administrators have full access to the > >> > file, the POSIX permssion bits will not reflect that fact. And while > >> > other users get access denied based on the mask value, SYSTEM and > >> > Administrators will never get access denied based on the mask. > >> > >> If you want to put this to better use in larger settings it would seem > >> preferrable if it was possible to define a list of users to treat this > >> way in fstab. > > > > Nope, sorry, no configuration for this. Either it's handled without > > any exception, or for SYSTEM only, or for SYSTEM+Admins. But either > > way, we're doing it the same way on every system. > > Damn. I was about to reply with Achim's exact same thought --- like a > file in /etc with a list of SIDs. I can empathize with Corinna's veto > though -- having a hundred tweak-able settings in Cygwin is > unmaintainable for the general populous. I may apply a local patch to > extend this ability myself because Cygwin has become rather unusable > for users with home's on our network drives (given all the programs > that attempt to do sanity checks on group perms). I'd suggest to give the new ACL handling sa try first. It might not be as bad (anymore) as you think. > That said, I appreciate what has been integrated --- it will help in > several scenarios. I will test the release this weekend. Thanks for > all the hard work! Thank you, 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 8:47 ` Achim Gratz 2015-04-11 9:02 ` David Macek 2015-04-11 9:44 ` Corinna Vinschen @ 2015-04-11 16:05 ` Andrey Repin 2 siblings, 0 replies; 42+ messages in thread From: Andrey Repin @ 2015-04-11 16:05 UTC (permalink / raw) To: Achim Gratz, cygwin Greetings, Achim Gratz! > Corinna Vinschen writes: >> - To accommodate Windows default ACLs, the new code ignores SYSTEM and >> Administrators group permissions when computing the MASK/CLASS_OBJ >> permission mask on old ACLs, and it doesn't deny access to SYSTEM and >> Administrators group based on the value of MASK/CLASS_OBJ when >> creating the new ACLs. > Since you've now opened that can of worms of who is considered "root", > what about "Domain Administrators" or "Power Users", for starters? "Domain Admins" is a members of local "Administrators" group. And "Power Users" are just users with a little more power, but not by much. -- With best regards, Andrey Repin Saturday, April 11, 2015 18:58:52 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-10 10:07 [TESTERS needed] New POSIX permission handling Corinna Vinschen ` (2 preceding siblings ...) 2015-04-11 8:47 ` Achim Gratz @ 2015-04-11 17:11 ` donmez 2015-04-12 8:35 ` Corinna Vinschen 3 siblings, 1 reply; 42+ messages in thread From: donmez @ 2015-04-11 17:11 UTC (permalink / raw) To: cygwin Hi, Corinna Vinschen-2 wrote > Hi folks, > > > I just applied a patch I'm working on for quite some time now. As I > outlined before on this list, the POSIX permission handling has aged > considerably and, for historical reasons, did things differently > dependent on the calling function. I took the time to reimplement the > core functionality to handle all ACLs as strictly following POSIX ACL > rules as possible. I tested the updated package and at least quilt and mutt seems to broken by the permission changes: [~]> quilt new foo cat: /tmp/quilt.mwTVWM: Permission denied Patch patches/foo is now on top And running mutt results in: "Error creating temporary file /tmp/mutt-...." Rolling back to an older snapshot fixes the problem. -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117455.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-11 17:11 ` donmez @ 2015-04-12 8:35 ` Corinna Vinschen 2015-04-12 13:21 ` İsmail Dönmez 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-12 8:35 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2530 bytes --] On Apr 11 10:11, donmez wrote: > Hi, > > > Corinna Vinschen-2 wrote > > Hi folks, > > > > > > I just applied a patch I'm working on for quite some time now. As I > > outlined before on this list, the POSIX permission handling has aged > > considerably and, for historical reasons, did things differently > > dependent on the calling function. I took the time to reimplement the > > core functionality to handle all ACLs as strictly following POSIX ACL > > rules as possible. > > I tested the updated package and at least quilt and mutt seems to broken by > the permission changes: > > [~]> quilt new foo > cat: /tmp/quilt.mwTVWM: Permission denied > Patch patches/foo is now on top > > And running mutt results in: > > "Error creating temporary file /tmp/mutt-...." > > Rolling back to an older snapshot fixes the problem. Thanks, but... No offense, but this is not overly helpful. The problem is to learn *why* this happens and how to fix it. For that I'd need to know what your permissions on /tmp look like (ls -l, getfacl, icacls). Creating files in my /tmp (having an old-style ACL) with the following permissions works as desired for me: $ uname -rm 2.0.0(0.287/5/3) x86_64 $ ls -ld /tmp drwxrwxrwt+ 1 corinna vinschen 0 Apr 12 10:25 /tmp $ getfacl /tmp # file: /tmp # owner: corinna # group: vinschen # flags: --t user::rwx group::rwx mask:rwx other:rwx default:user::rwx default:group::r-x default:mask:r-x default:other:r-x $ icacls C:\\cygwin64\\tmp C:\cygwin64\tmp VINSCHEN\corinna:(F) VINSCHEN\vinschen:(RX,W) Everyone:(RX,W) NULL SID:(RD) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files $ touch /tmp/foo $ ls -l /tmp/foo -rw-r--r-- 1 corinna vinschen 0 Apr 12 10:25 /tmp/foo $ getfacl /tmp/foo # file: /tmp/foo # owner: corinna # group: vinschen user::rw- group::r-x mask:r-- other:r-- $ icacls C:\\cygwin64\\tmp\\foo C:\cygwin64\tmp\foo NULL SID:(DENY)(Rc,S,X,DC) VINSCHEN\corinna:(R,W,D,WDAC,WO) VINSCHEN\vinschen:(DENY)(S,X) VINSCHEN\vinschen:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 files $ 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-12 8:35 ` Corinna Vinschen @ 2015-04-12 13:21 ` İsmail Dönmez 2015-04-12 14:25 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: İsmail Dönmez @ 2015-04-12 13:21 UTC (permalink / raw) To: cygwin Hi, Corinna Vinschen-2 wrote > On Apr 11 10:11, donmez wrote: >> Hi, >> >> >> Corinna Vinschen-2 wrote >> > Hi folks, >> > >> > >> > I just applied a patch I'm working on for quite some time now. As I >> > outlined before on this list, the POSIX permission handling has aged >> > considerably and, for historical reasons, did things differently >> > dependent on the calling function. I took the time to reimplement the >> > core functionality to handle all ACLs as strictly following POSIX ACL >> > rules as possible. >> >> I tested the updated package and at least quilt and mutt seems to broken >> by >> the permission changes: >> >> [~]> quilt new foo >> cat: /tmp/quilt.mwTVWM: Permission denied >> Patch patches/foo is now on top >> >> And running mutt results in: >> >> "Error creating temporary file /tmp/mutt-...." >> >> Rolling back to an older snapshot fixes the problem. > > Thanks, but... > > No offense, but this is not overly helpful. The problem is to learn > *why* this happens and how to fix it. For that I'd need to know what > your permissions on /tmp look like (ls -l, getfacl, icacls). Creating > files in my /tmp (having an old-style ACL) with the following > permissions works as desired for me: Hopefully this will shed some more light: [~]> uname -rm 2.0.0(0.287/5/3) x86_64 [~]> ls -ld /tmp drwxrwxrwt+ 1 ismail ismail 0 Apr 12 16:13 /tmp [~]> getfacl /tmp # file: /tmp # owner: ismail # group: ismail # flags: --t user::rwx user:ismail:rwx group::rwx mask:rwx other:rwx default:user::rwx default:group::r-x default:mask:r-x default:other:r-x [~]> icacls C:\\cygwin64\\tmp C:\cygwin64\tmp UX31A\ismail:(F) UX31A\ismail:(RX,W) Everyone:(RX,W) NULL SID:(RD) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files [~]> touch /tmp/foo [~]> ls -l /tmp/foo -rw-r--r--+ 1 ismail ismail 0 Apr 12 16:16 /tmp/foo [~]> getfacl /tmp/foo # file: /tmp/foo # owner: ismail # group: ismail user::rw- user:ismail:r-x group::--- mask:r-- other:r-- [~]> icacls C:\\cygwin64\\tmp\\foo C:\cygwin64\tmp\foo NULL SID:(DENY)(Rc,S,X,DC) UX31A\ismail:(DENY)(S,X) UX31A\ismail:(R,W,D,WDAC,WO) UX31A\ismail:(RX) UX31A\ismail:(DENY)(S,X) UX31A\ismail:(RX) Everyone:(R) Successfully processed 1 files; Failed processing 0 files <brown paper bag> I hope this to be a generic bug, skimmed over one important details. This is on Win 10 beta build 10049 x64</brown paper bag>. Thanks! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117479.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-12 13:21 ` İsmail Dönmez @ 2015-04-12 14:25 ` Corinna Vinschen 2015-04-15 15:42 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-12 14:25 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1983 bytes --] On Apr 12 06:21, İsmail Dönmez wrote: > Hi, > > > Corinna Vinschen-2 wrote > > On Apr 11 10:11, donmez wrote: > >> Hi, > >> > >> > >> Corinna Vinschen-2 wrote > >> > Hi folks, > >> > > >> > > >> > I just applied a patch I'm working on for quite some time now. As I > >> > outlined before on this list, the POSIX permission handling has aged > >> > considerably and, for historical reasons, did things differently > >> > dependent on the calling function. I took the time to reimplement the > >> > core functionality to handle all ACLs as strictly following POSIX ACL > >> > rules as possible. > >> > >> I tested the updated package and at least quilt and mutt seems to broken > >> by > >> the permission changes: > >> > >> [~]> quilt new foo > >> cat: /tmp/quilt.mwTVWM: Permission denied > >> Patch patches/foo is now on top > >> > >> And running mutt results in: > >> > >> "Error creating temporary file /tmp/mutt-...." > >> > >> Rolling back to an older snapshot fixes the problem. > > > > Thanks, but... > > > > No offense, but this is not overly helpful. The problem is to learn > > *why* this happens and how to fix it. For that I'd need to know what > > your permissions on /tmp look like (ls -l, getfacl, icacls). Creating > > files in my /tmp (having an old-style ACL) with the following > > permissions works as desired for me: > > Hopefully this will shed some more light: It does, thank you. The problem is the dreaded "owner == group" problem introduced with these weird Microsoft accounts. I completely forgot about this while implementing the new code. It's pretty tricky to get the Windows ACL right for this. Additionally the ACLs already created by setup are... borderline correct only. Back to the drawing board... 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-12 14:25 ` Corinna Vinschen @ 2015-04-15 15:42 ` Corinna Vinschen 2015-04-16 10:20 ` Ismail Donmez 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-15 15:42 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2625 bytes --] Hi Ismail, On Apr 12 16:25, Corinna Vinschen wrote: > On Apr 12 06:21, İsmail Dönmez wrote: > > Corinna Vinschen-2 wrote > > > On Apr 11 10:11, donmez wrote: > > >> Corinna Vinschen-2 wrote > > >> > I just applied a patch I'm working on for quite some time now. As I > > >> > outlined before on this list, the POSIX permission handling has aged > > >> > considerably and, for historical reasons, did things differently > > >> > dependent on the calling function. I took the time to reimplement the > > >> > core functionality to handle all ACLs as strictly following POSIX ACL > > >> > rules as possible. > > >> > > >> I tested the updated package and at least quilt and mutt seems to broken > > >> by > > >> the permission changes: > > >> [...] > > > No offense, but this is not overly helpful. The problem is to learn > > > *why* this happens and how to fix it. For that I'd need to know what > > > your permissions on /tmp look like (ls -l, getfacl, icacls). Creating > > > files in my /tmp (having an old-style ACL) with the following > > > permissions works as desired for me: > > > > Hopefully this will shed some more light: > > It does, thank you. The problem is the dreaded "owner == group" problem > introduced with these weird Microsoft accounts. I completely forgot > about this while implementing the new code. It's pretty tricky to get > the Windows ACL right for this. Additionally the ACLs already created > by setup are... borderline correct only. Back to the drawing board... I just applied a patch which is supposed to handle this owner==group scenario better. In short, Cygwin will try to handle POSIX user and group permissions separately, even if owner == group. This is basically a fake as far as the actual permissions of the account are concerned, but it allows applications still to chmod to different user and group perms. It just *looks* different in the end. The only restriction of this is that the POSIX user permissions are always changed so that the user perms are >= the group perms in this situation. So this: chmod 460 foo will be internally twisted into chmod 660 foo I uploaded new developer snapshots to https://cygwin.com/snapshots/ and I'm just uploading a 2.0.0-0.5 test release with this change. Please give either of them a try. I'd be interested in feedback, ideally with details if something doesn't work as desired. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-15 15:42 ` Corinna Vinschen @ 2015-04-16 10:20 ` Ismail Donmez 2015-04-16 11:03 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Ismail Donmez @ 2015-04-16 10:20 UTC (permalink / raw) To: cygwin Hi, Corinna Vinschen-2 wrote > Hi Ismail, > > On Apr 12 16:25, Corinna Vinschen wrote: >> On Apr 12 06:21, İsmail Dönmez wrote: >> > Corinna Vinschen-2 wrote >> > > On Apr 11 10:11, donmez wrote: >> > >> Corinna Vinschen-2 wrote >> > >> > I just applied a patch I'm working on for quite some time now. As >> I >> > >> > outlined before on this list, the POSIX permission handling has >> aged >> > >> > considerably and, for historical reasons, did things differently >> > >> > dependent on the calling function. I took the time to reimplement >> the >> > >> > core functionality to handle all ACLs as strictly following POSIX >> ACL >> > >> > rules as possible. >> > >> >> > >> I tested the updated package and at least quilt and mutt seems to >> broken >> > >> by >> > >> the permission changes: >> > >> [...] >> > > No offense, but this is not overly helpful. The problem is to learn >> > > *why* this happens and how to fix it. For that I'd need to know what >> > > your permissions on /tmp look like (ls -l, getfacl, icacls). >> Creating >> > > files in my /tmp (having an old-style ACL) with the following >> > > permissions works as desired for me: >> > >> > Hopefully this will shed some more light: >> >> It does, thank you. The problem is the dreaded "owner == group" problem >> introduced with these weird Microsoft accounts. I completely forgot >> about this while implementing the new code. It's pretty tricky to get >> the Windows ACL right for this. Additionally the ACLs already created >> by setup are... borderline correct only. Back to the drawing board... > > I just applied a patch which is supposed to handle this owner==group > scenario better. > > In short, Cygwin will try to handle POSIX user and group permissions > separately, even if owner == group. This is basically a fake as far > as the actual permissions of the account are concerned, but it allows > applications still to chmod to different user and group perms. It > just *looks* different in the end. > > The only restriction of this is that the POSIX user permissions are > always changed so that the user perms are >= the group perms in this > situation. So this: > > chmod 460 foo > > will be internally twisted into > > chmod 660 foo > > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ > and I'm just uploading a 2.0.0-0.5 test release with this change. I tested the new test release (rm -rfd the cygwin installation and re-installed from scratch just to be sure), my original testcase with quilt and mutt works, BUT now when I run make install inside mutt source it complains that /usr/bin/install cannot change permissions on the destination executables. Now this is a pretty vague error report but it might take some time before I can post an easily reproducable error. Because running the same command myself gives no error whatsoever. I'll try to come up with a better report. Thanks a lot! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117615.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-16 10:20 ` Ismail Donmez @ 2015-04-16 11:03 ` Corinna Vinschen 2015-04-16 16:09 ` Ismail Donmez 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-16 11:03 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1798 bytes --] On Apr 16 03:20, Ismail Donmez wrote: > Corinna Vinschen-2 wrote > > I just applied a patch which is supposed to handle this owner==group > > scenario better. > > > > In short, Cygwin will try to handle POSIX user and group permissions > > separately, even if owner == group. This is basically a fake as far > > as the actual permissions of the account are concerned, but it allows > > applications still to chmod to different user and group perms. It > > just *looks* different in the end. > > > > The only restriction of this is that the POSIX user permissions are > > always changed so that the user perms are >= the group perms in this > > situation. So this: > > > > chmod 460 foo > > > > will be internally twisted into > > > > chmod 660 foo > > > > > > I uploaded new developer snapshots to https://cygwin.com/snapshots/ > > and I'm just uploading a 2.0.0-0.5 test release with this change. > > I tested the new test release (rm -rfd the cygwin installation and > re-installed from scratch just to be sure), my original testcase with quilt > and mutt works, BUT now when I run make install inside mutt source it > complains that /usr/bin/install cannot change permissions on the destination > executables. Hmm, ok. Off the top of my head I don't understand this. > can post an easily reproducable error. Because running the same command > myself gives no error whatsoever. I'll try to come up with a better report. That would be nice. A good start would be to know what permission mask install is trying to set the destination to. Maybe that sheds some light. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-16 11:03 ` Corinna Vinschen @ 2015-04-16 16:09 ` Ismail Donmez 2015-04-16 16:24 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Ismail Donmez @ 2015-04-16 16:09 UTC (permalink / raw) To: cygwin Hi, Corinna Vinschen-2 wrote > On Apr 16 03:20, Ismail Donmez wrote: >> Corinna Vinschen-2 wrote >> > I just applied a patch which is supposed to handle this owner==group >> > scenario better. >> > >> > In short, Cygwin will try to handle POSIX user and group permissions >> > separately, even if owner == group. This is basically a fake as far >> > as the actual permissions of the account are concerned, but it allows >> > applications still to chmod to different user and group perms. It >> > just *looks* different in the end. >> > >> > The only restriction of this is that the POSIX user permissions are >> > always changed so that the user perms are >= the group perms in this >> > situation. So this: >> > >> > chmod 460 foo >> > >> > will be internally twisted into >> > >> > chmod 660 foo >> > >> > >> > I uploaded new developer snapshots to https://cygwin.com/snapshots/ >> > and I'm just uploading a 2.0.0-0.5 test release with this change. >> >> I tested the new test release (rm -rfd the cygwin installation and >> re-installed from scratch just to be sure), my original testcase with >> quilt >> and mutt works, BUT now when I run make install inside mutt source it >> complains that /usr/bin/install cannot change permissions on the >> destination >> executables. > > Hmm, ok. Off the top of my head I don't understand this. > >> can post an easily reproducable error. Because running the same command >> myself gives no error whatsoever. I'll try to come up with a better >> report. > > That would be nice. A good start would be to know what permission mask > install is trying to set the destination to. Maybe that sheds some light. So I am trying to configure and install mutt, and the first error I see is at the end of configure: configure: creating ./config.status chmod: changing permissions of './config.status': Permission denied configure: error: write failure creating ./config.status Well, looks like its right: [~/src/mutt]> chmod +x config.status chmod: changing permissions of ‘config.status’: Permission denied [~/src/mutt]> uname -a CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin [~/src/mutt]> getfacl . # file: . # owner: ismail # group: ismail user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:r-x other:r-x default:user::rwx default:group::r-x default:group:SYSTEM:rwx default:group:Administrators:rwx default:mask:r-x default:other:r-x [~/src/mutt]> getfacl config.status # file: config.status # owner: ismail # group: ismail user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:r-x other:r-x Any ideas? :) Thank you. -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117621.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-16 16:09 ` Ismail Donmez @ 2015-04-16 16:24 ` Corinna Vinschen 2015-04-16 16:48 ` Ismail Donmez 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-16 16:24 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1467 bytes --] On Apr 16 09:09, Ismail Donmez wrote: > Hi, > > [...] > So I am trying to configure and install mutt, and the first error I see is > at the end of configure: > > configure: creating ./config.status > chmod: changing permissions of './config.status': Permission denied > configure: error: write failure creating ./config.status > > Well, looks like its right: > > [~/src/mutt]> chmod +x config.status > chmod: changing permissions of ‘config.status’: Permission denied > > [~/src/mutt]> uname -a > CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin > > [~/src/mutt]> getfacl . > # file: . > # owner: ismail > # group: ismail > user::rwx > group::r-x > group:SYSTEM:rwx > group:Administrators:rwx > mask:r-x > other:r-x > default:user::rwx > default:group::r-x > default:group:SYSTEM:rwx > default:group:Administrators:rwx > default:mask:r-x > default:other:r-x > > [~/src/mutt]> getfacl config.status > # file: config.status > # owner: ismail > # group: ismail > user::rwx > group::r-x > group:SYSTEM:rwx > group:Administrators:rwx > mask:r-x > other:r-x > > Any ideas? :) Not yet. Can you add the output of icacls for both? For easier copy/pasting, just pipe the icacls output through `cat' for the time being. 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-16 16:24 ` Corinna Vinschen @ 2015-04-16 16:48 ` Ismail Donmez 2015-04-17 7:30 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Ismail Donmez @ 2015-04-16 16:48 UTC (permalink / raw) To: cygwin Corinna Vinschen-2 wrote > On Apr 16 09:09, Ismail Donmez wrote: >> Hi, >> >> [...] >> So I am trying to configure and install mutt, and the first error I see >> is >> at the end of configure: >> >> configure: creating ./config.status >> chmod: changing permissions of './config.status': Permission denied >> configure: error: write failure creating ./config.status >> >> Well, looks like its right: >> >> [~/src/mutt]> chmod +x config.status >> chmod: changing permissions of ‘config.status’: Permission denied >> >> [~/src/mutt]> uname -a >> CYGWIN_NT-6.3 ux31a 2.0.0(0.287/5/3) 2015-04-15 17:39 x86_64 Cygwin >> >> [~/src/mutt]> getfacl . >> # file: . >> # owner: ismail >> # group: ismail >> user::rwx >> group::r-x >> group:SYSTEM:rwx >> group:Administrators:rwx >> mask:r-x >> other:r-x >> default:user::rwx >> default:group::r-x >> default:group:SYSTEM:rwx >> default:group:Administrators:rwx >> default:mask:r-x >> default:other:r-x >> >> [~/src/mutt]> getfacl config.status >> # file: config.status >> # owner: ismail >> # group: ismail >> user::rwx >> group::r-x >> group:SYSTEM:rwx >> group:Administrators:rwx >> mask:r-x >> other:r-x >> >> Any ideas? :) > > Not yet. Can you add the output of icacls for both? For easier > copy/pasting, just pipe the icacls output through `cat' for the time > being. [~/src/mutt]> icacls config.status config.status NULL SID:(DENY)(Rc,S,REA,X,DC) UX31A\ismail:(F) UX31A\ismail:(RX) NT AUTHORITY\SYSTEM:(RX,W,DC) BUILTIN\Administrators:(RX,W,DC) Everyone:(RX) Successfully processed 1 files; Failed processing 0 files [~/src/mutt]> icacls . . NULL SID:(DENY)(Rc,S,REA,X,DC) UX31A\ismail:(F) UX31A\ismail:(RX) NT AUTHORITY\SYSTEM:(RX,W,DC) BUILTIN\Administrators:(RX,W,DC) Everyone:(RX) NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC) BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117627.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-16 16:48 ` Ismail Donmez @ 2015-04-17 7:30 ` Corinna Vinschen 2015-04-17 10:06 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-17 7:30 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1971 bytes --] Hi Ismail, On Apr 16 09:48, Ismail Donmez wrote: > Corinna Vinschen-2 wrote > > On Apr 16 09:09, Ismail Donmez wrote: > >> [~/src/mutt]> chmod +x config.status > >> chmod: changing permissions of ‘config.status’: Permission denied This is really surprising. > [~/src/mutt]> icacls config.status > config.status NULL SID:(DENY)(Rc,S,REA,X,DC) > UX31A\ismail:(F) > UX31A\ismail:(RX) > NT AUTHORITY\SYSTEM:(RX,W,DC) > BUILTIN\Administrators:(RX,W,DC) > Everyone:(RX) > > Successfully processed 1 files; Failed processing 0 files > > [~/src/mutt]> icacls . > . NULL SID:(DENY)(Rc,S,REA,X,DC) > UX31A\ismail:(F) > UX31A\ismail:(RX) > NT AUTHORITY\SYSTEM:(RX,W,DC) > BUILTIN\Administrators:(RX,W,DC) > Everyone:(RX) > NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC) > CREATOR OWNER:(OI)(CI)(IO)(F) > CREATOR GROUP:(OI)(CI)(IO)(RX) > NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC) > BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) > Everyone:(OI)(CI)(IO)(RX) I created the exact same scenario with the exact same ACLs, just with my own account as user and group, and I can't reproduce a "Permission denied". chmod simply works for me. Weird. While looking into this I found some other problems in this owner==group scenario, so I applied a few patches. I'm just creating new developer snapshots and a 2.0.0-0.6 test release. It would be nice if you could update, test again, and if the problem still occurs, I think I'll need an strace of the above chmod call as in: $ strace -o chmod.trace chmod +x config.status This combined with the icacls of the ACLs of config.status and the parent dir, just to be sure the new Cygwin created the same ACLs. Thanks in advance, 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-17 7:30 ` Corinna Vinschen @ 2015-04-17 10:06 ` Corinna Vinschen 2015-04-17 15:17 ` Ismail Donmez 0 siblings, 1 reply; 42+ messages in thread From: Corinna Vinschen @ 2015-04-17 10:06 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2205 bytes --] On Apr 17 09:30, Corinna Vinschen wrote: > Hi Ismail, > > On Apr 16 09:48, Ismail Donmez wrote: > > Corinna Vinschen-2 wrote > > > On Apr 16 09:09, Ismail Donmez wrote: > > >> [~/src/mutt]> chmod +x config.status > > >> chmod: changing permissions of ‘config.status’: Permission denied > > This is really surprising. > > > [~/src/mutt]> icacls config.status > > config.status NULL SID:(DENY)(Rc,S,REA,X,DC) > > UX31A\ismail:(F) > > UX31A\ismail:(RX) > > NT AUTHORITY\SYSTEM:(RX,W,DC) > > BUILTIN\Administrators:(RX,W,DC) > > Everyone:(RX) > > > > Successfully processed 1 files; Failed processing 0 files > > > > [~/src/mutt]> icacls . > > . NULL SID:(DENY)(Rc,S,REA,X,DC) > > UX31A\ismail:(F) > > UX31A\ismail:(RX) > > NT AUTHORITY\SYSTEM:(RX,W,DC) > > BUILTIN\Administrators:(RX,W,DC) > > Everyone:(RX) > > NULL SID:(OI)(CI)(IO)(DENY)(Rc,S,REA,X,DC) > > CREATOR OWNER:(OI)(CI)(IO)(F) > > CREATOR GROUP:(OI)(CI)(IO)(RX) > > NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(RX,W,DC) > > BUILTIN\Administrators:(OI)(CI)(IO)(RX,W,DC) > > Everyone:(OI)(CI)(IO)(RX) > > I created the exact same scenario with the exact same ACLs, just with my > own account as user and group, and I can't reproduce a "Permission > denied". chmod simply works for me. Weird. > > While looking into this I found some other problems in this owner==group > scenario, so I applied a few patches. I'm just creating new developer > snapshots and a 2.0.0-0.6 test release. > > It would be nice if you could update, test again, and if the problem > still occurs, I think I'll need an strace of the above chmod call as > in: > > $ strace -o chmod.trace chmod +x config.status > > This combined with the icacls of the ACLs of config.status and the > parent dir, just to be sure the new Cygwin created the same ACLs. I think I found the culprit. I'll uploade a -0.7 test release in the next hour or so. Thanks for testing, 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-17 10:06 ` Corinna Vinschen @ 2015-04-17 15:17 ` Ismail Donmez 2015-04-17 16:22 ` Corinna Vinschen 0 siblings, 1 reply; 42+ messages in thread From: Ismail Donmez @ 2015-04-17 15:17 UTC (permalink / raw) To: cygwin Hi, Corinna Vinschen-2 wrote > On Apr 17 09:30, Corinna Vinschen wrote: > I think I found the culprit. I'll uploade a -0.7 test release in > the next hour or so. So far all my tests work, thanks a bunch! -- View this message in context: http://cygwin.1069669.n5.nabble.com/TESTERS-needed-New-POSIX-permission-handling-tp117406p117666.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [TESTERS needed] New POSIX permission handling 2015-04-17 15:17 ` Ismail Donmez @ 2015-04-17 16:22 ` Corinna Vinschen 0 siblings, 0 replies; 42+ messages in thread From: Corinna Vinschen @ 2015-04-17 16:22 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 466 bytes --] On Apr 17 08:17, Ismail Donmez wrote: > Hi, > > > Corinna Vinschen-2 wrote > > On Apr 17 09:30, Corinna Vinschen wrote: > > I think I found the culprit. I'll uploade a -0.7 test release in > > the next hour or so. > > So far all my tests work, thanks a bunch! Thanks for your feedback! 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 --] ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2015-05-19 6:46 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-10 10:07 [TESTERS needed] New POSIX permission handling Corinna Vinschen 2015-04-10 21:13 ` Warren Young 2015-04-11 9:35 ` Corinna Vinschen 2015-04-11 0:00 ` Steven Penny 2015-04-11 9:40 ` Corinna Vinschen 2015-04-11 10:07 ` Corinna Vinschen 2015-04-11 16:26 ` Ernie Rael 2015-04-12 8:22 ` Corinna Vinschen 2015-04-11 10:23 ` Corinna Vinschen 2015-04-11 10:47 ` Steven Penny 2015-04-11 14:30 ` Corinna Vinschen 2015-04-11 16:05 ` Andrey Repin 2015-04-12 17:37 ` Adam Dinwoodie 2015-05-16 2:39 ` Steven Penny 2015-05-17 7:44 ` Duncan Roe 2015-05-19 7:52 ` Jiří Engelthaler 2015-04-11 8:47 ` Achim Gratz 2015-04-11 9:02 ` David Macek 2015-04-11 9:08 ` Achim Gratz 2015-04-11 9:51 ` David Macek 2015-04-11 11:51 ` Achim Gratz 2015-04-11 10:00 ` Corinna Vinschen 2015-04-11 12:36 ` David Macek 2015-04-11 14:31 ` Corinna Vinschen 2015-04-11 9:44 ` Corinna Vinschen 2015-04-11 11:11 ` Bryan Berns 2015-04-11 14:32 ` Corinna Vinschen 2015-04-11 16:05 ` Andrey Repin 2015-04-11 17:11 ` donmez 2015-04-12 8:35 ` Corinna Vinschen 2015-04-12 13:21 ` İsmail Dönmez 2015-04-12 14:25 ` Corinna Vinschen 2015-04-15 15:42 ` Corinna Vinschen 2015-04-16 10:20 ` Ismail Donmez 2015-04-16 11:03 ` Corinna Vinschen 2015-04-16 16:09 ` Ismail Donmez 2015-04-16 16:24 ` Corinna Vinschen 2015-04-16 16:48 ` Ismail Donmez 2015-04-17 7:30 ` Corinna Vinschen 2015-04-17 10:06 ` Corinna Vinschen 2015-04-17 15:17 ` Ismail Donmez 2015-04-17 16:22 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).