cygwin potentially corrupting permissions?
All, I've noticed on 2 different machines that if I copy (cp) a file I can read with cygwin, I don't have permission to read the copy. I don't recall that happening in that past. If this was Linux I would feel comfortable looking at umask, etc. to figure out what is going on. With cygwin I'm at a loss. If someone can tell me what I have configured wrong, I'd really appreciate it. fyi: I have a very vanilla install of cygwin on both machines. I've been using cygwin for many years and never noticed this before. It maybe an issue unique to Excel. Here's a scenario I just went through: 1) Use Excel (2010 or 2013) to create a simple 2 column, 3 row table and use "Save As" to save it as a CSV file name "Book1.csv" 2) verify it can be read via cygwin $ cat Book1.csv field1,field2 1,2 3,4 3) use cp to make a copy cp Book1.csv fail.csv 4) try to read the copy and fail $ cat fail.csv cat: fail.csv: Permission denied 5) Verify the owner / UID / perms are the same $ ls -l Book1.csv fail.csv rwx---+ 1 GAF None 25 Sep 23 18:45 Book1.csv rwx---+ 1 GAF None 25 Sep 23 18:46 fail.csv $ ls -ln Book1.csv fail.csv rwx---+ 1 1006 513 25 Sep 23 18:45 Book1.csv rwx---+ 1 1006 513 25 Sep 23 18:46 fail.csv They are, but there are extended attributes hiding behind the + sign. 6) Force the permissions and test again $ chmod +rw fail.csv $ cat fail.csv field1,field2 1,2 3,4 == Bewildered, Greg -- Greg Freemyer www.IntelligentAvatar.net -- 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: cygwin potentially corrupting permissions?
Greg Freemyer wrote: All, I've noticed on 2 different machines that if I copy (cp) a file I can read with cygwin, I don't have permission to read the copy. --- What does the acl say? (Attached a script, lsacl, that I use -- it works with linux or cygwin and allows wildcards). #!/bin/bash ## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp law $ # Version 2 -- try to work with getfacl on cygwin # shopt -s expand_aliases alias int=declare\ -i sub=function string=declare gfacl=$(type -P getfacl) if ! type -f cygwin 2>/dev/null ; then _un_=$(type -P uname) if [[ $_un_ ]] ; then _os_=$($_un_ -o); elif[[ -e /proc/sys/kernel ]]; then _os_=Linux; else_os_=Cygwin; fi if [[ $_os_ =~ Cygwin ]]; then function cygwin () { return 0; } elsefunction cygwin () { return 1; } fi unset _un_ _os_ export -f cygwin fi if cygwin 2>/dev/null ;then [[ $gfacl ]] || { printf "FATAL: Cannot find getfacl in path\n"; exit 1; } sub gfacl () { "$gfacl" "$@"; } else ## linux version has broken semantics requiring "-p" sub gfacl () { "$gfacl" -p "$@" ; } fi export -f gfacl sub facl2str { string fn=${1:?"Need pathname"} string s1='/^\#.*$/d; /^\s*$/d; s/\s*#.*$//; s/^(.)(ser|roup|ask|ther):/\1:/; y/\n/,/' string facl=$(gfacl -a "$fn"|sed -r "$s1"|tr "\n" ",") facl=${facl%,} string dacl=$(gfacl -d "$fn"|sed -r "s/^default://; $s1"|tr "\n" ",") dacl=${dacl%,} printf "[%s/%s]\n" "$facl" "$dacl" } int acllen=0 maxfnln=0 #for fn in "$@" ; do if ((maxfnln<${#fn})); then maxfnln=${#fn}; fi ; done sub acl_str () { if cygwin ;then perm=$(facl2str "$fn") else qfn=$(printf "%q " "$fn") out="$(chacl -l "$fn")" perm="${out#$qfn}" fi printf "%s\n" "$perm" } for fn in "$@"; do int max=40 perm=$(acl_str "$fn") int len=${#perm} if ((len>_acl_len_)); then acllen=len; fi if ((acllen>max)); then acllen=max; fi printf "%-${acllen}s %s\n" "$perm" "$fn" done -- 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: cygwin potentially corrupting permissions?
Linda, We seem to travel the same mailing lists. This is my first time to cygwin's. I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it My user id is "gaf". fyi: I thought I knew how to read an ACL, but the above makes little sense to me. Note I can cat out "lsacl.sh", but I can't cat out "it". Greg -- Greg Freemyer www.IntelligentAvatar.net On Wed, Sep 23, 2015 at 10:58 PM, Linda Walsh wrote: > Greg Freemyer wrote: >> >> All, >> >> I've noticed on 2 different machines that if I copy (cp) a file I can >> read with cygwin, I don't have permission to read the copy. > > --- > What does the acl say? > > (Attached a script, lsacl, that I use -- it works > with linux or cygwin and allows wildcards). > > > #!/bin/bash > > ## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp law $ > # Version 2 -- try to work with getfacl on cygwin > # > > > shopt -s expand_aliases > alias int=declare\ -i sub=function string=declare > > gfacl=$(type -P getfacl) > > if ! type -f cygwin 2>/dev/null ; then > _un_=$(type -P uname) > if [[ $_un_ ]] ; then _os_=$($_un_ -o); > elif[[ -e /proc/sys/kernel ]]; then _os_=Linux; > else_os_=Cygwin; > fi > if [[ $_os_ =~ Cygwin ]]; then function cygwin () { > return 0; } > elsefunction cygwin () { return 1; } > fi > unset _un_ _os_ > export -f cygwin > fi > > if cygwin 2>/dev/null ;then > [[ $gfacl ]] || { printf "FATAL: Cannot find getfacl in path\n"; > exit 1; } > sub gfacl () { "$gfacl" "$@"; } > else > ## linux version has broken semantics requiring "-p" > sub gfacl () { "$gfacl" -p "$@" ; } > fi > > export -f gfacl > > > sub facl2str { > string fn=${1:?"Need pathname"} > string s1='/^\#.*$/d; /^\s*$/d; s/\s*#.*$//; > s/^(.)(ser|roup|ask|ther):/\1:/; y/\n/,/' > string facl=$(gfacl -a "$fn"|sed -r "$s1"|tr "\n" ",") > facl=${facl%,} > string dacl=$(gfacl -d "$fn"|sed -r "s/^default://; $s1"|tr "\n" > ",") > dacl=${dacl%,} > printf "[%s/%s]\n" "$facl" "$dacl" > } > > > > int acllen=0 maxfnln=0 > #for fn in "$@" ; do if ((maxfnln<${#fn})); then maxfnln=${#fn}; fi ; done > > sub acl_str () { > if cygwin ;then > perm=$(facl2str "$fn") > else > qfn=$(printf "%q " "$fn") > out="$(chacl -l "$fn")" > perm="${out#$qfn}" > fi > printf "%s\n" "$perm" > } > > > for fn in "$@"; do > int max=40 > perm=$(acl_str "$fn") > int len=${#perm} > if ((len>_acl_len_)); then acllen=len; fi > if ((acllen>max)); then acllen=max; fi > printf "%-${acllen}s %s\n" "$perm" "$fn" > done > -- 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: cygwin potentially corrupting permissions?
Greg Freemyer wrote: Linda, I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it --- Well user 'gaf' (that's you, from the file perms has no access). So up front, you are denied before anything happens. lsacl is the embedded acl (the '+') at the end of the file perms u::--- = user seen by 'ls -l' has no access, g::--- = group seen by 'ls -l has no access g:root:rwx = group root has read/write/execute access g:Authenticated Users:rwx == group consisting of Authenticated Users... (after you login or provide credentials). m:rwx m = a maximum allowed privs 'mask' for user/groups other than owner, but since all bits are turned on, it has no limiting effect o:--- = other has no access So the main take-away is that since your 'user' has no access, pretty much everything else is ignored. From the mode-bits+acl, amost anyone in the groups: root, Authenticated Users,SYSTEM, or Users, ***except** User 'gaf' (you) should have access... you might try 1) chmod u+rwx file ... then look at both mode+acl... if you have no access and acl still says u::---, then nuke the acl or modify it with "setfacl" (setfacl --help)... We seem to travel the same mailing lists. This is my first time to cygwin's. Yeah... I wondered about that -- my Tbird tried to change my reply addr to suse(at)tlinx based on you being the 1st address I typed in... ;-) -- 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: cygwin potentially corrupting permissions?
Greetings, Greg Freemyer! > We seem to travel the same mailing lists. This is my first time to cygwin's. > I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to > make a copy. > The copy is permission denied for reading. Basic ls -l shows no > difference (as expected) > $ ls -l lsacl.sh it > rwx---+ 1 gaf None 1630 Sep 24 12:05 it > rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh Notice the "+" at the end of basic POSIX access bits. And use getfacl (or native icacl(s)) to view real permissions. > But your script does show a difference: > $ ./lsacl.sh lsacl.sh it > [u::---,g::---,g:root:rwx,g:Authenticated > Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh > [u::---,g::r-x,g:root:rwx,g:Authenticated > Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it > My user id is "gaf". > fyi: I thought I knew how to read an ACL, but the above makes little > sense to me. Note I can cat out "lsacl.sh", but I can't cat out "it". Your system seems to be mangled. There should be no "root" user. Also, please avoid top posting as per list rules. -- With best regards, Andrey Repin Thursday, September 24, 2015 21:35:24 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: cygwin potentially corrupting permissions?
On Thu, Sep 24, 2015 at 2:06 PM, Linda Walsh wrote: > Greg Freemyer wrote: >> >> Linda, > > >> I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to >> make a copy. >> >> The copy is permission denied for reading. Basic ls -l shows no >> difference (as expected) >> >> $ ls -l lsacl.sh it >> rwx---+ 1 gaf None 1630 Sep 24 12:05 it >> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh >> >> But your script does show a difference: >> >> $ ./lsacl.sh lsacl.sh it >> [u::---,g::---,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh >> [u::---,g::r-x,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it > > --- > Well user 'gaf' (that's you, from the file perms has no access). > > So up front, you are denied before anything happens. Totally logical, but not accurate. ) I am the owner of both "it" and "lsacl.sh." For both the user permissions are "---" (why I don't know. I created lsacl.sh by a simple drag and drop out of firefox.) I can cat out "lsacl.sh", but not "it". I know "chmod +rw it" gives me access to the file. The problem is Windows is creating files with permissions like lsacl.sh routinely on my system. Then when I do anything to them in cygwin, the permissions are modified to block my access. I first noticed this because I was exporting CSV files from excel, then editing them with vi from cygwin. On the first edit, all was good. After that, I no longer had permission to access the file. So, either: - Windows 7 (on 2 different machines) has started using default permissions that are bad on their face - cygwin is not properly maintaining the permissions when it manipulates a file Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. Greg > lsacl is the embedded acl (the '+') at the end of the file perms > > u::--- = user seen by 'ls -l' has no access, g::--- = group seen by 'ls -l > has no access > g:root:rwx = group root has read/write/execute access > g:Authenticated Users:rwx == group consisting of Authenticated Users... > (after you login or provide credentials). > m:rwx m = a maximum allowed privs 'mask' for user/groups other > than owner, but since all bits are turned on, it has no limiting > effect > o:--- = other has no access > > So the main take-away is that since your 'user' has no access, pretty much > everything else is ignored. > > From the mode-bits+acl, amost anyone in the groups: > root, Authenticated Users,SYSTEM, or Users, ***except** User 'gaf' (you) > should have access... > > you might try 1) chmod u+rwx file ... > then look at both mode+acl... if you have no access > and acl still says u::---, then nuke the acl or modify it with "setfacl" > (setfacl --help)... > >> >> We seem to travel the same mailing lists. This is my first time to >> cygwin's. >> > > Yeah... I wondered about that -- my Tbird tried to change my > reply addr to suse(at)tlinx based on you being the 1st address I typed > in... ;-) -- 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: cygwin potentially corrupting permissions?
On 9/24/2015 2:52 PM, Greg Freemyer wrote: On Thu, Sep 24, 2015 at 2:06 PM, Linda Walsh wrote: Greg Freemyer wrote: Linda, I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it --- Well user 'gaf' (that's you, from the file perms has no access). So up front, you are denied before anything happens. Totally logical, but not accurate. ) I am the owner of both "it" and "lsacl.sh." For both the user permissions are "---" (why I don't know. I created lsacl.sh by a simple drag and drop out of firefox.) I can cat out "lsacl.sh", but not "it". I know "chmod +rw it" gives me access to the file. The problem is Windows is creating files with permissions like lsacl.sh routinely on my system. Then when I do anything to them in cygwin, the permissions are modified to block my access. I first noticed this because I was exporting CSV files from excel, then editing them with vi from cygwin. On the first edit, all was good. After that, I no longer had permission to access the file. So, either: - Windows 7 (on 2 different machines) has started using default permissions that are bad on their face - cygwin is not properly maintaining the permissions when it manipulates a file Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. The problem could be caused by the default ACL on whatever directory you're working in. You might consider running 'setfacl -b' and/or 'setfacl -k' on that directory. (Run 'setfacl --help' for more information.) 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: cygwin potentially corrupting permissions?
Andrey Repin wrote: Your system seems to be mangled. There should be no "root" user. Also, please avoid top posting as per list rules. You are missing one? Don't tell me, you have Administrator instead? Maybe that's why you see Greg's messages as top-posted, where as I saw him as interleaving his response w/what I said? ;-) If you have Win7-Pro or above, you can rename Admin and Guest accounts -- which is recommended for security reasons. If you read windows 'rules', you'd know that... (so many rules to read...really hard for someone to keep up)... *cheers* -l -- 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: cygwin potentially corrupting permissions?
Greg Freemyer wrote: Totally logical, but not accurate. ) --- What does it say if you do an 'lsacl' on "." (the parent directory). This is a local file system? NTFS? Do you have process hacker? Maybe the writing process has a different integrity label or such. Process hacker lets you see what the integrity labels are on files, but to see what they are on files you'd have to d/l another util. (chml/regil - cygwin is not properly maintaining the permissions when it manipulates a file May not be able to ... Windows trumps cygwin. MS-regularly screws w/windows, .. it's like switching to a new init system every month... ok.. maybe not quite that bad... Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. === I can understand that -- that's sorta why I haven't upgraded my cygwin lately -- She spent alot of time solving a problem that didn't really appear on my system, so changing the whole security system -- well I already know that cygwin doesn't respect existing standards or sources. (overwrite windows mount points created -- and is shipping a login that zeros your environment -- even when passed switch to not do so -- effectively wipes your windows session -- forcing users to copy sessions from static files to get around the problem. -- 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: cygwin potentially corrupting permissions?
Greetings, Linda Walsh! > Andrey Repin wrote: >> Your system seems to be mangled. There should be no "root" user. >> >> Also, please avoid top posting as per list rules. > > You are missing one? Don't tell me, you have > Administrator instead? No, I have my own account, that's quite enough. > Maybe that's why you see Greg's messages as top-posted, where > as I saw him as interleaving his response w/what I said? ;-) > If you have Win7-Pro or above, you can rename Admin > and Guest accounts -- You can rename them in NT4, too. Just sayin'. > which is recommended for security reasons. Obscurity has no relation to security. Oh, and these both are disabled on my systems. > If you read windows 'rules', you'd know that... (so many rules > to read...really hard for someone to keep up)... There's no such rules as "rename default accounts". It makes no sense and bears no reason. -- With best regards, Andrey Repin Friday, September 25, 2015 04:43:28 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: cygwin potentially corrupting permissions?
On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh wrote: > Greg Freemyer wrote: >> >> >> Totally logical, but not accurate. ) > > --- > What does it say if you do an 'lsacl' on "." (the parent directory). $ ./lsacl.sh . [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] . But maybe this is interesting. I just created 2 folders in C:\ . I did it at the C:\ level because I can't imagine I ever modified the ACLs on C:\. Anyway, one directory was created via "mkdir" in cygwin. The other via the file explorer. Look at how different the ACLs are: $ mkdir /cygdrive/c/Test-dir-created-in-cygwin $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/ [u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x] /cygdrive/c/Test-dir-created-in-cygwin/ $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/ [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] /cygdrive/c/Test-dir-created-in-file-explorer/ What's that about? Again I'm not expert at ACLs, but the ACLs on the directory created via File Explorer look really strange to me. > This is a local file system? NTFS? Yes, C: drive. It's my local system drive on both computers and NTFS on both machines. > Do you have process hacker? Maybe the writing process has a different > integrity label or such. No, but let me know if you still want me to pursue that. For now I'm thinking the ACLs on folders created via File Explorer are somehow getting screwed up. Thanks Greg > Process hacker lets you see what the integrity labels are on files, > but to see what they are on files you'd have to d/l another util. > (chml/regil > >> >> - cygwin is not properly maintaining the permissions when it manipulates a >> file > > > May not be able to ... Windows trumps cygwin. > MS-regularly screws w/windows, .. it's like switching to a new > init system every month... ok.. maybe not quite that bad... > >> >> Either way, I would really like a solution that doesn't involve a >> manual chmod for every file I create via the normal Windows interface >> and which I want to work with it in cygwin. > > === > I can understand that -- that's sorta why I haven't upgraded > my cygwin lately -- She spent alot of time solving a problem that didn't > really appear on my system, so changing the whole security system -- well > I already know that cygwin doesn't respect existing standards or sources. > (overwrite windows mount points created -- and is shipping a login that > zeros your environment -- even when passed switch to not do so -- > effectively > wipes your windows session -- forcing users to copy sessions from static > files to get around the problem. > -- 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: cygwin potentially corrupting permissions?
On Thu, Sep 24, 2015 at 2:37 PM, Andrey Repin wrote: > Greetings, Greg Freemyer! > >> We seem to travel the same mailing lists. This is my first time to cygwin's. > >> I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to >> make a copy. > >> The copy is permission denied for reading. Basic ls -l shows no >> difference (as expected) > >> $ ls -l lsacl.sh it >> rwx---+ 1 gaf None 1630 Sep 24 12:05 it >> rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh > > Notice the "+" at the end of basic POSIX access bits. > And use getfacl (or native icacl(s)) to view real permissions. I'm using Linda' script that does that, but here's the raw getfacl output for 2 folders created in C:\Note they have very different ACLs. Why? $ getfacl /cygdrive/c/Test-dir-created-in-cygwin/ # file: /cygdrive/c/Test-dir-created-in-cygwin/ # owner: GAF # group: None user::rwx group::r-x group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:r-x $ getfacl /cygdrive/c/Test-dir-created-in-file-explorer/ # file: /cygdrive/c/Test-dir-created-in-file-explorer/ # owner: GAF # group: None user::--- group::--- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- That last one with the directory created via file explorer has truly bizarre (to me) ACLs. Normal? If not, how do I fix it. Note I have 2 different Win 7 boxes showing this same behavior. > >> But your script does show a difference: > >> $ ./lsacl.sh lsacl.sh it >> [u::---,g::---,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh >> [u::---,g::r-x,g:root:rwx,g:Authenticated >> Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it > >> My user id is "gaf". > >> fyi: I thought I knew how to read an ACL, but the above makes little >> sense to me. Note I can cat out "lsacl.sh", but I can't cat out "it". > > Your system seems to be mangled. There should be no "root" user. hmm. I think that is a "root" group, not a "root" user. I seriously doubt I created a root as a group. Are you sure that isn't standard with cygwin? note: I love using cygwin, but I'm not very knowledgeable about user and group management in cygwin. On the other hand, I'm pretty good at it in Linux. (I'm a 30+ year UNIX/Linux user) > Also, please avoid top posting as per list rules. If I did, I will try to avoid it in the future. This e-mail is interspersed. I assume that is desired. Greg -- 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: cygwin potentially corrupting permissions?
On Thu, Sep 24, 2015 at 3:22 PM, Ken Brown wrote: > > > The problem could be caused by the default ACL on whatever directory you're > working in. You might consider running 'setfacl -b' and/or 'setfacl -k' on > that directory. (Run 'setfacl --help' for more information.) I just posted this, but it looks like directories created in cygwin have reasonable ACLs, but directories created via "File Explorer" are bizarre. Where bizzare is defined as: $ getfacl /cygdrive/c/Test-dir-created-in-file-explorer/ # file: /cygdrive/c/Test-dir-created-in-file-explorer/ # owner: GAF # group: None user::--- group::--- group:root:rwx group:Authenticated Users:rwx group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- Here's getfacl for C:\ $ getfacl /cygdrive/c # file: /cygdrive/c # owner: TrustedInstaller # group: TrustedInstaller user::--- group::--- group:root:rwx group:Authenticated Users:--- group:SYSTEM:rwx group:Users:r-x mask:rwx other:--- default:user::--- default:group::--- default:group:root:rwx default:group:Authenticated Users:rwx default:group:SYSTEM:rwx default:group:Users:r-x default:mask:rwx default:other:--- Is that what others have? fyi: I just realized I installed "System Mechanic" around the time I started seeing problems. It is installed on both of the machines having issues. I wonder if it adulterated my ACLs in an attempt to make my machine safer? Thanks Greg -- 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: cygwin potentially corrupting permissions?
On Thu, Sep 24, 2015 at 9:46 PM, Andrey Repin wrote: > Obscurity has no relation to security Tell any Army in the world about that theory. They should save their money wasted on camouflage, stealth technology, etc. But, I did not knowingly add the "root" group. Greg -- 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: cygwin potentially corrupting permissions?
Andrey Repin wrote: Obscurity has no relation to security. Oh, and these both are disabled on my systems. If you read windows 'rules', you'd know that... (so many rules to read...really hard for someone to keep up)... There's no such rules as "rename default accounts". It makes no sense and bears no reason. --- Security best practices : See "https://technet.microsoft.com/en-us/library/cc747353%28v=ws.10%29.aspx"; and "https://technet.microsoft.com/en-us/library/jj852273.aspx"; -- 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: cygwin potentially corrupting permissions?
Greg Freemyer wrote: On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh wrote: Greg Freemyer wrote: Totally logical, but not accurate. ) --- What does it say if you do an 'lsacl' on "." (the parent directory). $ ./lsacl.sh . [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] . But maybe this is interesting. I just created 2 folders in C:\ . I did it at the C:\ level because I can't imagine I ever modified the ACLs on C:\. Anyway, one directory was created via "mkdir" in cygwin. The other via the file explorer. Look at how different the ACLs are: $ mkdir /cygdrive/c/Test-dir-created-in-cygwin $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/ [u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x] /cygdrive/c/Test-dir-created-in-cygwin/ $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/ [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] /cygdrive/c/Test-dir-created-in-file-explorer/ What's that about? Again I'm not expert at ACLs, but the ACLs on the directory created via File Explorer look really strange to me. - That looks like the 'Creator User & Creator Group Policies at work, which try to let you create a dir in root, but give limited access to that dir -- but doesn't allow just any Creator to have full access... I think you are seeing a trickle down effect from the creator owner policy and the creator group policy banning full access -- because if you look at the security tab in explorer I'll be those are pretty restricted... This is a local file system? NTFS? Yes, C: drive. It's my local system drive on both computers and NTFS on both machines. Do you have process hacker? Maybe the writing process has a different integrity label or such. Look at the acl in the Explorer 'security tab' You find some extra rules for 'creators' that are supposed to allow them to do things inside the dir but not to the dir or some such. No, but let me know if you still want me to pursue that. For now I'm thinking the ACLs on folders created via File Explorer are somehow getting screwed up. 'screwed-up' is relative -- i.e. in this case, likely what explorer is designed to do, (screw you), *str8-face*... In the home directory you want to deal with this in (I wouldn't suggest changing drives from root folder (I do such things and constantly end up with 'shot-in-foot' type problems that I get to have 'fun' fixing! ;->) But get rid of the creator rules so they won't propagate have to do it from windows those because those entities aren't posix. -- 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: cygwin potentially corrupting permissions?
Greetings, Linda Walsh! > Andrey Repin wrote: >> Obscurity has no relation to security. >> Oh, and these both are disabled on my systems. >> >>> If you read windows 'rules', you'd know that... (so many rules >>> to read...really hard for someone to keep up)... >> >> There's no such rules as "rename default accounts". >> It makes no sense and bears no reason. > --- > Security best practices : > See "https://technet.microsoft.com/en-us/library/cc747353%28v=ws.10%29.aspx"; > and "https://technet.microsoft.com/en-us/library/jj852273.aspx"; Bullshit. Both of them. You may "guess this user name and password combination" of a disabled account to your heart's content. It'll won't do square shit. The only times where you use the default administrator account is when you run domain recovery script from recovery console. And recovery console does not use the account name, neither check for status. It only ask for password. Solution: Ban default accounts and let attackers try their luck. @Greg Freemyer: An "army in the world" does not have passwords and firewalls. That's the only reason they are trying to rely on obscurity. Doesn't quite work, as attacker could just carpet bomb the target positions. -- With best regards, Andrey Repin Friday, September 25, 2015 11:14:20 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: cygwin potentially corrupting permissions?
Andrey Repin wrote: @Greg Freemyer: An "army in the world" does not have passwords and firewalls. That's the only reason they are trying to rely on obscurity. Doesn't quite work, as attacker could just carpet bomb the target positions. --- password = obscure secret; crypto = hidden secrets that take time to find. Both are a form of obscurity. -- 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