X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Tue, 1 Apr 2008 15:44:24 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Building perl-5.10.0
Message-ID:	<20080401134424.GS4468@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<7634A226C4C245868140309A0F3A952F AT desktop2> <2kap83p6s5819lu66sr6kmrem6o5iqm180 AT 4ax DOT com> <56E5E10621694E4A860212458ECD1E1C AT desktop2> <015b01c7bf20$a3d3e4a0$2e08a8c0 AT CAM DOT ARTIMI DOT COM> <F3A6993B1B3741AD9B6A6D9688BB301D AT desktop2> <9ea6aaa80803172015i3adb46cq3af80a70fa7ff063 AT mail DOT gmail DOT com> <AD1B0F102FEA451BB4C3CB6F44F0B9F5 AT desktop2> <47E5384E DOT 3070503 AT x-ray DOT at> <47E711BE DOT 2020608 AT byu DOT net> <20080401132111 DOT GR4468 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20080401132111.GR4468@calimero.vinschen.de>
User-Agent:	Mutt/1.5.16 (2007-06-09)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Apr  1 15:21, Corinna Vinschen wrote:
> Hi Eric,
> 
> On Mar 23 20:28, Eric Blake wrote:
> >   POSIX also states that chmod(2) is
> > supposed to disable any ACLs that allow alternate access.
> 
> How long did you know that this is wrong in Cygwin?  I was really
> surprised to read that.  Maybe you told me already and I ignored it.
> One of the Cygwin patches in 2001 was to change the alloc_sd function so
> that unrelated ACEs are not touched when changing the ACEs reflecting
> the standard file permission bits.  It never occured to any of us that
> this might be wrong.  Oh well.  I'll look into changing that for 1.7.0.

Erm... hang on.  I just tested this on Linux:

  $ touch xxx
  $ getfacl xxx
  # file: xxx
  # owner: corinna
  # group: users
  user::rw-
  group::r--
  mask::r--
  other::r--

  $ setfacl -m u:nobody:r-- xxx
  $ getfacl xxx
  # file: xxx
  # owner: corinna
  # group: users
  user::rw-
  user:nobody:r--
  group::r--
  mask::r--
  other::r--

  $ chmod 666 xxx
  $ getfacl xxx
  # file: xxx
  # owner: corinna
  # group: users
  user::rw-
  user:nobody:r--
  group::r--
  mask::rw-
  other::rw-

This looks like what we do on Cygwin, too.  Shouldn't the "nobody" entry
disappear when calling chmod?  That's how I understand the statement in
the POSIX docs:

 "An alternate file access control mechanism shall [...] be disabled for
  a file after the file permission bits are changed for that file with
  chmod( ).  The disabling of the alternate mechanism need not disable
  any additional mechanisms supported by an implementation."

Either the ACLs of a file are not an "alternate" access mechanism,
but an "additional" access mechanism.  But that doesn't match the
description either:

 "An additional access control mechanism shall only further restrict
  the access permissions defined by the file permission bits."

Or, Linux doesn't follow POSIX here, which seems unlikely to me.

Or, I completly misunderstand what the above quote means.


Any comment?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -