From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53602 invoked by alias); 11 Apr 2015 16:26:41 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 53591 invoked by uid 89); 11 Apr 2015 16:26:41 -0000 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 Received: from resqmta-po-03v.sys.comcast.net (HELO resqmta-po-03v.sys.comcast.net) (96.114.154.162) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 11 Apr 2015 16:26:39 +0000 Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-03v.sys.comcast.net with comcast id EgSc1q0054xDoy801gSdFV; Sat, 11 Apr 2015 16:26:37 +0000 Received: from [IPv6:::1] ([IPv6:2601:9:7280:72e0:19bd:64fe:8f47:c5d2]) by resomta-po-05v.sys.comcast.net with comcast id EgSc1q00G1veEeY01gSduQ; Sat, 11 Apr 2015 16:26:37 +0000 Message-ID: <55294B35.8050708@raelity.com> Date: Sat, 11 Apr 2015 16:26:00 -0000 From: Ernie Rael 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@cygwin.com Subject: Re: [TESTERS needed] New POSIX permission handling References: <20150410100703.GA4401@calimero.vinschen.de> <20150411094020.GB19111@calimero.vinschen.de> <20150411100752.GE19111@calimero.vinschen.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 X-SW-Source: 2015-04/txt/msg00215.txt.bz2 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