From: Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)
Date: Fri, 06 Jul 2007 09:24:05 -0400
Message-ID: <1183728245.6463.17.camel@heimdal.trondhjem.org>
References: <a90f74cc0707051401p38167340s955be299a807710d@mail.gmail.com>
	<468D6064.3080307@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: nfs@lists.sourceforge.net
To: Peter Staubach <staubach@redhat.com>
In-Reply-To: <468D6064.3080307@redhat.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Thu, 2007-07-05 at 17:19 -0400, Peter Staubach wrote:
> Actually, all that the "noacl" mount option means is to not attempt
> to get or set or ACLs on the server.  It does not affect the security
> checking that the client does to verify access.
> 
> The permission bits are not enough to determine access permissions.
> Root mapping on the server is an easy example of this.  Therefore,
> the client always goes over the wire to query the server for the
> permissions that it will allow.

Right. The confusion here stems from the fact that SuSE attempted to
make "noacl" mean both "I will not get/set any posix acls" and "there
are no acls on the server" in their kernels.

The common practice of root mapping blows that argument right out of the
water, and so I never applied the parts of their ACL patches that switch
off ACCESS calls.

Trond


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs