Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

Sam Falkner <Sam.Falkner@Sun.COM> Sat, 15 July 2006 13:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kdG-0003L8-EC; Sat, 15 Jul 2006 09:56:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kdF-0003GD-2P for nfsv4@ietf.org; Sat, 15 Jul 2006 09:56:33 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1kdD-0003DM-EQ for nfsv4@ietf.org; Sat, 15 Jul 2006 09:56:33 -0400
Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6FDuPku001257 for <nfsv4@ietf.org>; Sat, 15 Jul 2006 07:56:31 -0600 (MDT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J2G002012YCIH00@mail-amer.sun.com> (original mail from Sam.Falkner@Sun.COM) for nfsv4@ietf.org; Sat, 15 Jul 2006 07:56:25 -0600 (MDT)
Received: from [10.0.1.2] ([67.165.213.100]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J2G00IRR6Q01IC1@mail-amer.sun.com>; Sat, 15 Jul 2006 07:56:25 -0600 (MDT)
Date: Sat, 15 Jul 2006 07:56:23 -0600
From: Sam Falkner <Sam.Falkner@Sun.COM>
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
In-reply-to: <20060711134635.GA11586@fieldses.org>
To: "J. Bruce Fields" <bfields@fieldses.org>
Message-id: <CB8011E1-395C-46D7-9F3A-4E75DDB080D4@Sun.COM>
MIME-version: 1.0
X-Mailer: Apple Mail (2.752.2)
Content-type: text/plain; format="flowed"; delsp="yes"; charset="US-ASCII"
Content-transfer-encoding: 7bit
References: <200607032310.15252.agruen@suse.de> <200607110215.53496.agruen@suse.de> <3E4B637E-57AC-4E2B-A2C8-EDCFF35A5D84@Sun.COM> <200607111005.22200.agruen@suse.de> <67359DB9-6E3E-49E7-A8F6-3FB34DCC3440@Sun.COM> <20060711134635.GA11586@fieldses.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Lisa Week <Lisa.Week@Sun.COM>, nfsv4@ietf.org, nfs@lists.sourceforge.net, Spencer Shepler <spencer.shepler@Sun.COM>, Brian Pawlowski <beepy@netapp.com>, Andreas Gruenbacher <agruen@suse.de>
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
Errors-To: nfsv4-bounces@ietf.org

On Jul 11, 2006, at 9:46 AM, J. Bruce Fields wrote:

> On Tue, Jul 11, 2006 at 08:29:21AM -0400, Sam Falkner wrote:
>> That's not how Solaris works either.  Sorry, I should have explained
>> it better.  In Solaris using POSIX-draft ACLs, chmod() changes both
>> the group permissions and the mask, simultaneously.  I now understand
>> why you were hesitant to have chmod affect the group permissions, but
>> having it affect both mask and group solves both problems.
>
> I think you're missing the point of his example.  The point is that a
> chmod-using application may expect the sequence chmod(600) chmod 
> (664) on
> a file with mode 664 to be a no-op.
>
> But if chmod() changes both group and mask bits ("owning group" and
> "group file class" bits) then this sequence isn't a no-op any more in
> his example.  It gives GROUP@ write permissions.

Okay, understood.

> So Andreas is trying to ensure the property that any sequence of  
> chmod's
> that leaves the mode bits the same also leaves the ACL the same.  I
> agree that that's a nice property.

Perhaps, but I think having chmod unable to set the mode to be a much  
more undesirable property, to put it mildly.

> What I'm not convinced of yet is that this is really worth caring  
> about
> much.  Is this common application behavior?  Have there been  
> complaints
> about this from people using Solaris's ACLs?

I did some more research, and found that the Solaris chmod() system  
call does pretty much what Linux does -- the group permissions of  
chmod() affect the mask, not the group permission bits.  Originally,  
the chmod command did the chmod() system call, and not much else.

There were many complaints about this.  So many that the chmod  
command line was changed to do the chmod() system call, and then, in  
the presence of an ACL, fix the permission bits.  In other words, the  
bug was fixed.

I have found no complaints about the current Solaris behavior, where  
chmod affects group permissions.

- Sam

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4