Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
Andreas Gruenbacher <agruen@suse.de> Tue, 11 July 2006 08:08 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0DI7-0006m2-IU; Tue, 11 Jul 2006 04:08:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0DI6-0006lw-F0 for nfsv4@ietf.org; Tue, 11 Jul 2006 04:08:22 -0400
Received: from ns2.suse.de ([195.135.220.15] helo=mx2.suse.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0DI3-00031C-Sh for nfsv4@ietf.org; Tue, 11 Jul 2006 04:08:22 -0400
Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 5BA261EC19; Tue, 11 Jul 2006 10:08:18 +0200 (CEST)
From: Andreas Gruenbacher <agruen@suse.de>
Organization: Novell / SUSE Labs
To: Sam Falkner <Sam.Falkner@sun.com>
Subject: Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready
Date: Tue, 11 Jul 2006 10:05:21 +0200
User-Agent: KMail/1.9.1
References: <200607032310.15252.agruen@suse.de> <200607110215.53496.agruen@suse.de> <3E4B637E-57AC-4E2B-A2C8-EDCFF35A5D84@Sun.COM>
In-Reply-To: <3E4B637E-57AC-4E2B-A2C8-EDCFF35A5D84@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200607111005.22200.agruen@suse.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: Lisa Week <Lisa.Week@sun.com>, nfsv4@ietf.org, "J. Bruce Fields" <bfields@fieldses.org>, nfs@lists.sourceforge.net, Spencer Shepler <spencer.shepler@sun.com>, Brian Pawlowski <beepy@netapp.com>
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 Tuesday, 11. July 2006 07:42, Sam Falkner wrote: > >> I think having chmod be functional, i.e. chmod 770 gives write > >> permission to the owning group, and an "ls -l" shows "rwxrwx---", > >> would be best by far. > > > > It screws you when you want to give the owning group fewer permissions > > than other users in the File Group Class. This can be worked around by > > creating a dummy group with no members, or one group that only contains > > a single user for each user, and changing the owning group of files, but > > the owning group already has other defined uses in POSIX (think of SETGID > > for files and directories), and so it's not desirable and not always > > possible to change the owning group to such a dummy group. > > No -- if you want owning group to have fewer permissions than other > users, you're using an ACL. You use tools that manipulate ACLs. Sorry, but while this may look like a good idea at first, it doesn't work very well. Let's look at an example: OWNER@:READ_DATA/WRITE_DATA::ALLOW GROUP@:READ_DATA/WRITE_DATA::ALLOW user@domain:READ_DATA/WRITE_DATA::ALLOW EVERYONE:READ_DATA::ALLOW The mode is rw-rw-r--. Now we use ACL tools to change the ACL to give the owning group fewer permissions than user@domain as you say: OWNER@:READ_DATA/WRITE_DATA::ALLOW GROUP@:READ_DATA::ALLOW user@domain:READ_DATA/WRITE_DATA::ALLOW EVERYONE:READ_DATA::ALLOW The mode must still be rw-rw-r-- because otherwise, user@domain wouldn't have WRITE_DATA access. Now a nasty, evil POSIX application that doesn't know anything about ACLs comes along and does a chmod(file, 0600), chmod(file, 0664). What should be the appropriate result? If changing the group file mode permission bits writes through to the GROUP@ entry as you say, then we would end up with the following *effective* permissions: OWNER@:READ_DATA/WRITE_DATA::ALLOW GROUP@:READ_DATA/WRITE_DATA::ALLOW user@domain:READ_DATA/WRITE_DATA::ALLOW EVERYONE:READ_DATA::ALLOW (The effective permissions are the same no matter how permissions are masked in the ACL, be it via DENY ACEs or via masks. In the case of DENY ACEs, the ACL would contain DENY entries, but those wouldn't mask any permissions in this case. The example is slightly more difficult to think through with DENY ACEs because they contain some redudancy and potential for inconsistencies, but the result is the same.) From the POSIX application's point of view, the file has the same permissions before and after the chmod. The POSIX application cannot be held guilty; after all it doesn't know about ACLs by definition. Yet the acl actually grants more permissions after the chmods, and the change we did to give the owning group fewer permissions with ACL tools is lost. This can be quite serious. We can play the same example with MAY_WRITE vs. MAY_APPEND: if the group file mode permission bits write through to the owning group permissions, a POSIX chmod may convert a MAY_APPEND owning group ACE into a MAY_WRITE owning group ACE. > Solaris' POSIX-draft ACLs have the property that chmod works (i.e. > you can set group permissions), and you use setfacl if you want to > change other entries. It's perfectly easy to have owning group have > fewer permissions than supplimental users. That's a bug, and draft 17 of POSIX 1003.1e (withdrawn) has this bug fixed. > The bottom line is that chmod must set the mode, rather than "set the > mode, unless there's some sort of ACL thingy, in which case the group > bits aren't the group bits but are instead the mask bits". We may be misunderstanding here: I agree that chmod must set the file mode (permission bits as well as special bits). The point is that the group file mode permission bits can no longer be the same as the owning group permissions with ACLs, or else innocent POSIX applications may cause unintended side effects as in the example. Andreas -- Andreas Gruenbacher <agruen@suse.de> Novell / SUSE Labs _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] NFSv4 ACL and POSIX interaction / mask Andreas Gruenbacher
- [nfsv4] Re: NFSv4 ACL and POSIX interaction / mas… Andreas Gruenbacher
- [nfsv4] Re: NFSv4 ACL and POSIX interaction / mas… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Lisa Week
- [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask David Collier-Brown
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… Sam Falkner
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Lisa Week
- Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interac… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… J. Bruce Fields
- [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interaction… J. Bruce Fields
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… J. Bruce Fields
- RE: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… wurzl_mario
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… Andreas Gruenbacher
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… Andreas Gruenbacher
- Re: [nfsv4] Re: [NFS] NFSv4 ACL and POSIX interac… J. Bruce Fields
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Sam Falkner
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Lisa Week
- Re: [nfsv4] Re: NFSv4 ACL and POSIX interaction /… Andreas Gruenbacher