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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=qTDbc6Whm0F4HglVYpwRJlEc6gVAnO0+MUWLkKU9FTT
	ASGiYaEWyreswp52scyC8OqHALTWXt0V2eRIkY7nN4KQBpljN/HUtKiFcV3jLOff
	yX8n4Hab/UOX4DTGx179yDulEjaDcW+HaMeKqDBBc3po+qpUBk5L9F3vJVDBI7I8
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=/a7llssWVsH76/I+F6ctP16ZjKA=; b=yTPoedj04KA2EwvXn
	/NnSIl38/8dZEJcAGB5UfqGSP9No7ecRSNdON7a/30IsYBCbArhFi/CuRWOy4aNS
	HdzTrkt+5iGcBRj0bSHslvk1xH+mxjY7gX8/kQe+zL3zbhO80FpPv6RE6ywJEplj
	Lpzo5/icVvf8Q76Q72iRGxM9oU=
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=0.8 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-HELO: resqmta-po-03v.sys.comcast.net
Message-ID: <55294B35.8050708@raelity.com>
Date: Sat, 11 Apr 2015 09:26:29 -0700
From: Ernie Rael <err AT raelity DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [TESTERS needed] New POSIX permission handling
References: <20150410100703 DOT GA4401 AT calimero DOT vinschen DOT de> <CAAXzdLUFeBX6EREpMA2WeMYT+oS8c=JXhqkwrvNYUGjsWFrW8w AT mail DOT gmail DOT com> <20150411094020 DOT GB19111 AT calimero DOT vinschen DOT de> <20150411100752 DOT GE19111 AT calimero DOT vinschen DOT de>
In-Reply-To: <20150411100752.GE19111@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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