This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: cacls combination problem in 1.7.35, merging privs of existing file & privs of process
- From: John Ruckstuhl <john dot ruckstuhl at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 22 Jun 2015 14:15:49 -0700
- Subject: Re: cacls combination problem in 1.7.35, merging privs of existing file & privs of process
- Authentication-results: sourceware.org; auth=none
- References: <019E497FEC593443965FC4E5BB0F628C5AA08C74 at SV950-MBX1 dot corp dot intusurg dot com>
- Reply-to: John dot Ruckstuhl at gmail dot com
On Sat, Jun 20, 2015 at 11:41 AM, John Ruckstuhl
<John.Ruckstuhl@intusurg.com> wrote:
>
> I'm noticing this summer, that whenever I try to edit an existing file with vi for the first time, the file's permissions change. Could this be a problem with merging permissions of existing file and permissions of the vi process?
To clarify, for me, when the vi process is writing out a fresh file,
the new file gets an acl ... Then when vi overwrites that file
(presumably creating a new file with an acl per the merging of the
existing acl and new-file acl, the result is different acl. The file
when first written -- execution via the shebang works. When updated,
something -- the file or the shebang -- doesn't execute anymore.
I believe this is easily reproducible (1.7.35). My umask is 0022.
1. In vi, create 2 lines of content including a shebang, like this:
!# /usr/bin/sh
date
2. write it out to a file, like try.sh
3. execute it
./try.sh
it works, right?
4. write the file back out a 2nd time (no changes)
5. execute it again
./try.sh
but this time, it doesn't work
-bash: ./try.sh: Permission denied
6. now delete the shebang line, and write the file out (3rd time)
7. execute it again
./try.sh
it works again. Huh?
So yes I am still puzzled about the acl diff between the 1st & 2nd
file-write, and also it looks like it's a shebang interaction.
FWIW, I think my user sid & group sid are different. See Footnote [3] below.
Best regards,
John
Footnotes
[3]
I claim user sid & group sid are different because id says:
uid=1158474(johnru) gid=1049089(Domain Users)
groups=1049089(Domain
Users),544(Administrators),545(Users),4(INTERACTIVE),66049(CONSOLE
LOGON),11(Authenticated Users),15(This
Organization),4095(CurrentSession),66048(LOCAL),1058289(Corporate
Employees), ...
and the RIDs are different (109898 != 513) (btw, is this the accepted
technique to get SID?):
C:\Users\johnru>wmic useraccount where name='JohnRu' get sid
SID
S-1-5-21-25853599-488532567-929701000-109898
C:\Users\johnru>wmic group where name='Domain Users' get sid
SID
S-1-5-21-25853599-488532567-929701000-513
>
> Original cacls of file try2.txt:
> try2.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(R)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(F)
> BUILTIN\Administrators:(F)
> Cacls after vi open & write back out (":wq")
> try2.txt INTSURG\johnru:(DENY)(S,X)
> INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(RX,W)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(RX,W)
> BUILTIN\Administrators:(RX,W)
> Note 1 added deny line, and 3 lines changed from (R) or (F), to (RX,W).
>
> Or see differing getfacl output... try1.txt is a fresh file, try2.txt is a file re-written by vi session:
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ getfacl . try*
> # file: .
> # owner: johnru
> # group: Domain Users
> user::rwx
> group::r-x
> group:SYSTEM:rwx
> group:Administrators:rwx
> mask:rwx
> other:r-x
> default:user::rwx
> default:group::r-x
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:mask:rwx
> default:other:r-x
>
> # file: try1.txt
> # owner: johnru
> # group: Domain Users
> user::rw-
> group::r--
> group:SYSTEM:rwx
> group:Administrators:rwx
> mask:rwx
> other:r--
>
> # file: try2.txt
> # owner: johnru
> # group: Domain Users
> user::rw-
> group::rwx
> group:SYSTEM:rwx
> group:Administrators:rwx
> mask:rwx
> other:r--
>
>
> From the same shell, writing out a file by two techniques yields different cacls.
> Please help me understand the phenomenon.
> I am suspecting vi (or a library it calls) which tries to combine existing privileges of a file with the privs of the vi process, to generate privileges of the new file created on ":w".
> I am not asking for this behavior to be changed, and yes I'm expecting the behavior is different with Cygwin 2.0 .
> I am just trying to understand what is happening here, and which sw app or library is defining this behavior. Is it vi? Is it the cygwin1.dll?
> Sorry, I am using the terms privilege, permission, and cacl interchangeably out of ignorance.
> Also, I have tried to read https://cygwin.com/cygwin-ug-net/ntsec.html . Sorry, I don't see that it documents this phenomenon. I looked in mailing-list archives, and I couldn't connect the dots. Again this is 1.7.35 .
> cygcheck.out is attached.
> id.out is attached.
>
> Use case:
> I create a file by redirecting stdout to a file.
> Then I open in vi and write it back out (":wq") and its cacls have changed. Notably, as you can see, I no longer have "execute" permission.
> Is this a feature of vi, of bash, or of cygwin?
>
> It seems like bash & vi are using different techniques for determining how to specify the cacls of a new file (vi creating a new file on write).
> I know that over the past six months, cygwin handling of acls has been a topic of discussion.
> Also note,
> (a) this is on my C drive, under my Desktop, not on some remote fileserver.
> (b) Windows 7.
> (c) my IT dept routinely gives power-users Window Administrator privileges, so I have that, even though I'm not sure I want that attached to my day-to-day account.
> (d) while I am making these observations, I am at home, not on my domain network.
>
> Below, my control case is try1.txt, and my experiment is try2.txt (see Footnote [1]).
>
> Hmmm what if I write a new file with vi (instead of rewriting a file).
> Ahhh, In the new file case, vi writes file with same cacls as a fresh file written by shell redirect.
> Maybe what I'm observing is vi is trying to respect the original cacls when creating the updated file.
> So it's a problem with vi's attempt to combine the files original cacls with vi's notion of the privileges of its own process... (see Footnote [2])
>
> Footnotes
> [1]
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ icacls .
> . INTSURG\johnru:(F)
> INTSURG\Domain Users:(RX)
> Everyone:(RX)
> NT AUTHORITY\SYSTEM:(OI)(CI)(F)
> BUILTIN\Administrators:(OI)(CI)(F)
> 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
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ date > try1.txt
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ date > try2.txt
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ icacls try1.txt; icacls try2.txt
> try1.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(R)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(F)
> BUILTIN\Administrators:(F)
>
> Successfully processed 1 files; Failed processing 0 files
> try2.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(R)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(F)
> BUILTIN\Administrators:(F)
>
> Successfully processed 1 files; Failed processing 0 files
>
> (now edit file "try2.txt", and write it back out ":wq")
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ vi try2.txt
>
> (cacls have been changed! )
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ icacls try1.txt; icacls try2.txt
> try1.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(R)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(F)
> BUILTIN\Administrators:(F)
>
> Successfully processed 1 files; Failed processing 0 files
> try2.txt INTSURG\johnru:(DENY)(S,X)
> INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(RX,W)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(RX,W)
> BUILTIN\Administrators:(RX,W)
>
> Successfully processed 1 files; Failed processing 0 files
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ ls -la
> total 6
> drwxrwxr-x+ 1 johnru Domain Users 0 Jun 20 09:34 .
> drwxrwx---+ 1 Administrators Domain Users 0 Jun 20 09:32 ..
> -rw-rwxr--+ 1 johnru Domain Users 30 Jun 20 09:33 try1.txt
> -rw-rwxr--+ 1 johnru Domain Users 30 Jun 20 09:34 try2.txt
>
>
> [2] file "try3.txt" doesn't exist yet. Using vi to create it with the following command
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ vi try3.txt
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ icacls try3.txt
> try3.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(R)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(F)
> BUILTIN\Administrators:(F)
>
> Successfully processed 1 files; Failed processing 0 files
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ icacls try3.txt
> try3.txt INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(R)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(F)
> BUILTIN\Administrators:(F)
>
> Successfully processed 1 files; Failed processing 0 files
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ vi try3.txt
>
> johnru@JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ icacls try3.txt
> try3.txt INTSURG\johnru:(DENY)(S,X)
> INTSURG\johnru:(R,W,D,WDAC,WO)
> INTSURG\Domain Users:(RX,W)
> Everyone:(R)
> NT AUTHORITY\SYSTEM:(RX,W)
> BUILTIN\Administrators:(RX,W)
>
> Successfully processed 1 files; Failed processing 0 files
>
>
>
>
> --
> 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
--
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