Mail Archives: cygwin/2015/06/22/17:16:09
| X-Recipient: | archive-cygwin AT delorie DOT com
|
| DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
|
| :list-unsubscribe:list-subscribe:list-archive:list-post
|
| :list-help:sender:mime-version:reply-to:in-reply-to:references
|
| :date:message-id:subject:from:to:content-type; q=dns; s=default; b=
|
| KlPrsLEKW3KClF49E0pOZ2uFoCEC+56k5OIuacY0OXj4h58qG4/S1M3DpCYZz31u
|
| g7DSuyPgFxd+sZ23+seW5GGof6AerOQu86gw32cjZzls1bIzzvxZRKdYWHqq5Y3N
|
| dUddk9bG0cmvfGASkkzEDQZjT3ry2h6rzENHgV+Y2Kg=
|
| DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
|
| :list-unsubscribe:list-subscribe:list-archive:list-post
|
| :list-help:sender:mime-version:reply-to:in-reply-to:references
|
| :date:message-id:subject:from:to:content-type; s=default; bh=sM3
|
| 21pIf3KWDQUsTKuQxsvrptFc=; b=oJHdMvBnTlWulJu9zuWodU8uj2NqMFiOaXq
|
| a4CHliZtidfgCGtwzdbCvYk/6O4eqhsevhYU8AUporyE72gkeAUrf40Q+zYVkSVE
|
| M9M2+dPnupogWWqhpy11Nfl2MOgvGpnUizni6tHd4veDEYMGbDkHFHfPKkPA54Cv
|
| +TYPR6MQ=
|
| Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm
|
| List-Id: | <cygwin.cygwin.com>
|
| List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
| List-Archive: | <http://sourceware.org/ml/cygwin/>
|
| List-Post: | <mailto:cygwin AT cygwin DOT com>
|
| List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
| Sender: | cygwin-owner AT cygwin DOT com
|
| Mail-Followup-To: | cygwin AT cygwin DOT com
|
| Delivered-To: | mailing list cygwin AT cygwin DOT com
|
| Authentication-Results: | sourceware.org; auth=none
|
| X-Virus-Found: | No
|
| X-Spam-SWARE-Status: | No, score=4.9 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
|
| X-HELO: | mail-oi0-f50.google.com
|
| MIME-Version: | 1.0
|
| X-Received: | by 10.202.188.139 with SMTP id m133mr25286707oif.73.1435007750008; Mon, 22 Jun 2015 14:15:50 -0700 (PDT)
|
| Reply-To: | John DOT Ruckstuhl AT gmail DOT com
|
| In-Reply-To: | <019E497FEC593443965FC4E5BB0F628C5AA08C74@SV950-MBX1.corp.intusurg.com>
|
| References: | <019E497FEC593443965FC4E5BB0F628C5AA08C74 AT SV950-MBX1 DOT corp DOT intusurg DOT com>
|
| Date: | Mon, 22 Jun 2015 14:15:49 -0700
|
| Message-ID: | <CAOBROv3gK-1GgBd6DaYK92Vt2L5ZPhymMxDGy-8rB0hGd6=VSg@mail.gmail.com>
|
| Subject: | 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
|
| X-IsSubscribed: | yes
|
On Sat, Jun 20, 2015 at 11:41 AM, John Ruckstuhl
<John DOT Ruckstuhl AT intusurg DOT 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 AT 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 AT 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 AT JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ date > try1.txt
>
> johnru AT JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ date > try2.txt
>
> johnru AT 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 AT JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ vi try2.txt
>
> (cacls have been changed! )
> johnru AT 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 AT 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 AT JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ vi try3.txt
>
> johnru AT 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 AT 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 AT JohnRu-L1 ~/Desktop/dev NSIS/foul
> $ vi try3.txt
>
> johnru AT 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
- Raw text -