Re: umask not working?
Greetings, Achim Gratz! > David Allsopp writes: >>> You have extended ACL on the object. And overall, umask is not a good >>> idea in Windows. >> >> "umask is not a good idea in Windows" - where's that come from? > Ask three people and get at least seven answers. > Actually Windows is a red herring IMHO, Not so much a red herring, but it was mentioned in the reply to the specific issue, also because of how Windows actually implemented access control, which is much more sane than simple POSIX permissions. > it's the combination of umask > with DACL is the thing that doesn't mix well unless you keep it in a > very tight box. In your case, if you'd just remove the DACL from the > directories your repo is in (and any files and directories below > assuming that the ownership is the same for all of them) it'll probably > immediately start working as you expect it to. Depending on which > volume the directory is actually on and what WIndows software tries to > touch it you might find that some of these come back after a while, I > generally avoid any system volume for that reason. > Regards, > Achim. -- With best regards, Andrey Repin Thursday, March 22, 2018 01:09:01 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: umask not working?
On 2018-03-21 12:47, Achim Gratz wrote: > David Allsopp writes: >>> You have extended ACL on the object. And overall, umask is not a good >>> idea in Windows. >> >> "umask is not a good idea in Windows" - where's that come from? > > Ask three people and get at least seven answers. > > Actually Windows is a red herring IMHO, it's the combination of umask > with DACL is the thing that doesn't mix well unless you keep it in a > very tight box. In your case, if you'd just remove the DACL from the > directories your repo is in (and any files and directories below > assuming that the ownership is the same for all of them) it'll probably > immediately start working as you expect it to. Depending on which > volume the directory is actually on and what WIndows software tries to > touch it you might find that some of these come back after a while, I > generally avoid any system volume for that reason. If users remove directory DACLs, they should never try to use any non-Cygwin programs to create or use files in those directories: without DACLs, files created by non-Cygwin programs will have no access permissions, and can not be accessed by any programs without elevated admin rights. To support the interoperability offered by Cygwin, most users should ensure that Cygwin directory DACLs match the default umask, so that all programs can create, use, and change files in those directories. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: umask not working?
David Allsopp writes: >> You have extended ACL on the object. And overall, umask is not a good >> idea in Windows. > > "umask is not a good idea in Windows" - where's that come from? Ask three people and get at least seven answers. Actually Windows is a red herring IMHO, it's the combination of umask with DACL is the thing that doesn't mix well unless you keep it in a very tight box. In your case, if you'd just remove the DACL from the directories your repo is in (and any files and directories below assuming that the ownership is the same for all of them) it'll probably immediately start working as you expect it to. Depending on which volume the directory is actually on and what WIndows software tries to touch it you might find that some of these come back after a while, I generally avoid any system volume for that reason. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: umask not working?
Ken Brown wrote: > On 3/21/2018 6:36 AM, David Allsopp wrote: > > Ken Brown > >> On 3/19/2018 8:48 AM, David Allsopp wrote: > >>> Is this expected behaviour: > >>> > >>> OPAM+DRA@OPAM ~ > >>> $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir > >>> /tmp/bar ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW > >>> OPAM > >>> 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin > >>> 0022 > >>> -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo > >>> -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo > >>> > >>> Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm > >>> not sure what to look at on my system to diagnose what I may have > >>> inadvertently tweaked. The directory itself is: > >>> > >>> drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar > >> > >> See if this helps: > >> > >> https://cygwin.com/faq/faq.html#faq.using.same-with-permissions > > > > Thanks for the pointer. I wonder from it if this could be to do with > the Cygwin installation being old (but upgraded). I tried on the same > machine creating another installation to C:\cygwin2 (which behaves as > Roger Wells noted) and then ran getfacl /tmp on each: > > > > Old installation: > > > > # file: /tmp > > # owner: OPAM+DRA-Admin > > # group: OPAM+None > > user::rwx > > user:OPAM+DRA:rwx > > group::r-x > > mask:rwx > > other:r-x > > default:user::rwx > > default:user:OPAM+DRA:rwx > > default:group::r-x > > default:mask:rwx > > default:other:r-x > > > > Fresh installation: > > > > # file: /tmp > > # owner: OPAM+DRA-Admin > > # group: OPAM+None > > # flags: --t > > user::rwx > > group::rwx > > other:rwx > > default:user::rwx > > default:group::r-x > > default:other:r-x > > > > I expect that the extra OPAM+DRA:rwx on the old installation was > manually added by me, years ago. What are the "mask" entries all about? > > > > The default:mask entry seems to be the crucial one, as if I do setfacl > default:mask:rwx /tmp on the fresh installation, then I get the same > behaviour as on the old installation. > > > > However, I'm struggling to find references for either what these mask > entries are, or how they ever appeared? > > If you search the web for "Posix acl mask" you'll find lots of > information. Here's one that seems pretty good: > >https://cs.unc.edu/help-article/posix-acls-in-linux/ Indeed, I got a lot further once I stopped looking for Cygwin-specific info. The most useful part was eventually finding this in the umask(2) man page (http://man7.org/linux/man-pages/man2/umask.2.html): "Alternatively, if the parent directory has a default ACL (see acl(5)), the umask is ignored". Which explains why I was seeing that behaviour, and it was owing to having added my user account (the OPAM+DRA) to the ACL as that of course added w to the mask. Thanks for the help! David -- 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: umask not working?
On 3/21/2018 6:36 AM, David Allsopp wrote: Ken Brown On 3/19/2018 8:48 AM, David Allsopp wrote: Is this expected behaviour: OPAM+DRA@OPAM ~ $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin 0022 -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure what to look at on my system to diagnose what I may have inadvertently tweaked. The directory itself is: drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar See if this helps: https://cygwin.com/faq/faq.html#faq.using.same-with-permissions Thanks for the pointer. I wonder from it if this could be to do with the Cygwin installation being old (but upgraded). I tried on the same machine creating another installation to C:\cygwin2 (which behaves as Roger Wells noted) and then ran getfacl /tmp on each: Old installation: # file: /tmp # owner: OPAM+DRA-Admin # group: OPAM+None user::rwx user:OPAM+DRA:rwx group::r-x mask:rwx other:r-x default:user::rwx default:user:OPAM+DRA:rwx default:group::r-x default:mask:rwx default:other:r-x Fresh installation: # file: /tmp # owner: OPAM+DRA-Admin # group: OPAM+None # flags: --t user::rwx group::rwx other:rwx default:user::rwx default:group::r-x default:other:r-x I expect that the extra OPAM+DRA:rwx on the old installation was manually added by me, years ago. What are the "mask" entries all about? The default:mask entry seems to be the crucial one, as if I do setfacl default:mask:rwx /tmp on the fresh installation, then I get the same behaviour as on the old installation. However, I'm struggling to find references for either what these mask entries are, or how they ever appeared? If you search the web for "Posix acl mask" you'll find lots of information. Here's one that seems pretty good: https://cs.unc.edu/help-article/posix-acls-in-linux/ 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: umask not working?
Greetings, David Allsopp! > Andrey Repin wrote: >> Greetings, David Allsopp! >> >> > Is this expected behaviour: >> >> > OPAM+DRA@OPAM ~ >> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar >> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM >> > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin >> > 0022 >> > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo >> > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo >> >> > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not >> > sure what to look at on my system to diagnose what I may have >> > inadvertently tweaked. The directory itself is: >> >> > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar >> >> Let me guess, /tmp usertemp ? > No - it's default mounts, so /tmp = C:\cygwin\tmp, to which my > (non-administrative) user has write access. >> You have extended ACL on the object. And overall, umask is not a good >> idea in Windows. > "umask is not a good idea in Windows" - where's that come from? From knowledge and experience. umask is strictly simple POSIX modes concept. In the ACL environment it is anything from inappropriate to disastrous, but never useful. > (In the actual scenario where I'm being bitten by this, it's because a git > checkout is altering files which were 644 to be 664, so whether it's > precisely umask or not, the *change* of permissions is the problem). Use setfacl. -- With best regards, Andrey Repin Wednesday, March 21, 2018 15:32:21 Sorry for my terrible english...
RE: umask not working?
Ken Brown > On 3/19/2018 8:48 AM, David Allsopp wrote: > > Is this expected behaviour: > > > > OPAM+DRA@OPAM ~ > > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar > > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM > > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin > > 0022 > > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo > > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo > > > > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not > > sure what to look at on my system to diagnose what I may have > > inadvertently tweaked. The directory itself is: > > > > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar > > See if this helps: > >https://cygwin.com/faq/faq.html#faq.using.same-with-permissions Thanks for the pointer. I wonder from it if this could be to do with the Cygwin installation being old (but upgraded). I tried on the same machine creating another installation to C:\cygwin2 (which behaves as Roger Wells noted) and then ran getfacl /tmp on each: Old installation: # file: /tmp # owner: OPAM+DRA-Admin # group: OPAM+None user::rwx user:OPAM+DRA:rwx group::r-x mask:rwx other:r-x default:user::rwx default:user:OPAM+DRA:rwx default:group::r-x default:mask:rwx default:other:r-x Fresh installation: # file: /tmp # owner: OPAM+DRA-Admin # group: OPAM+None # flags: --t user::rwx group::rwx other:rwx default:user::rwx default:group::r-x default:other:r-x I expect that the extra OPAM+DRA:rwx on the old installation was manually added by me, years ago. What are the "mask" entries all about? The default:mask entry seems to be the crucial one, as if I do setfacl default:mask:rwx /tmp on the fresh installation, then I get the same behaviour as on the old installation. However, I'm struggling to find references for either what these mask entries are, or how they ever appeared? Thanks! David
RE: umask not working?
Andrey Repin wrote: > Greetings, David Allsopp! > > > Is this expected behaviour: > > > OPAM+DRA@OPAM ~ > > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar > > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM > > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin > > 0022 > > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo > > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo > > > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not > > sure what to look at on my system to diagnose what I may have > > inadvertently tweaked. The directory itself is: > > > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar > > Let me guess, /tmp usertemp ? No - it's default mounts, so /tmp = C:\cygwin\tmp, to which my (non-administrative) user has write access. > You have extended ACL on the object. And overall, umask is not a good > idea in Windows. "umask is not a good idea in Windows" - where's that come from? (In the actual scenario where I'm being bitten by this, it's because a git checkout is altering files which were 644 to be 664, so whether it's precisely umask or not, the *change* of permissions is the problem). David -- 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: umask not working?
On 3/19/2018 8:48 AM, David Allsopp wrote: Is this expected behaviour: OPAM+DRA@OPAM ~ $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin 0022 -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure what to look at on my system to diagnose what I may have inadvertently tweaked. The directory itself is: drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar See if this helps: https://cygwin.com/faq/faq.html#faq.using.same-with-permissions 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: umask not working?
Greetings, David Allsopp! > Is this expected behaviour: > OPAM+DRA@OPAM ~ > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ; > touch /tmp/bar/foo ; ls -l /tmp/bar/foo > CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin > 0022 > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure > what to look at on my system to diagnose what I may have inadvertently > tweaked. The directory itself is: > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar Let me guess, /tmp usertemp ? You have extended ACL on the object. And overall, umask is not a good idea in Windows. -- With best regards, Andrey Repin Monday, March 19, 2018 20:06:19 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
