From: Taylor_Tad@emc.com
Date: 04/10/02-03:29:35 PM Z
From: Taylor_Tad@emc.com
Message-ID: <6335CBB2F69AD411AD3100D0B7BA38E3040F6B2C@CORPUSMX2>
Subject: RE: Interaction between mode bits and acls
Date: Wed, 10 Apr 2002 16:29:35 -0400
I wasn't thinking about mode bits also being a recommended attribute, sorry.
I looked to make sure they weren't mandatory and forgot about looking there.
I agree with you that a well-defined algorithm is better than everyone
having their own solution. Access control should be as deterministic as
possible for users. That said, I believe that the existance of an ACL
should override what the mode bits say. The access control check should be
one or the other, but not both.
That leaves open the issue of how changes to mode bits would be reflected in
ACLs. The mode bits could be "translated" into ACL terms and added to the
ACL (I believe this is what the defunct POSIX spec did when a user did a
chmod on a file with an extended ACL, although that's an easier case).
Setting the mode bits could override (i.e., remove) the ACL, or we could
define a process for having both and coming up with an algorithm of how they
would be used simultaneously.
As for the point below about having to worry about both sets of attributes,
if I set an ACL that allows a user read access, do I have to make sure that
the mode bits don't also grant write access? That is, if both values can
exist on a file and both be referenced when checking a user's access, do I
have to set both sets of attributes when I change access control rights?
-----Original Message-----
From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]
Sent: Wednesday, April 10, 2002 3:46 PM
To: 'Taylor_Tad@emc.com'; Noveck, Dave; beame@bws.com;
nfsv4-wg@sunroof.eng.sun.com; Khan, Saadia
Subject: RE: Interaction between mode bits and acls
Taylor_Tad@emc.com wrote:
> Actually, as I think about the original question below, I realize that
it's
> presupposing the existance of mode bits in addition to ACLs. That might
not
> be the case for all servers, so I don't think the spec should say anything
> about it.
The question is how to address the interaction of mode bits and acl's when
they both exist. ACL's and mode bits are both recommended attributes.
As a practical matter, NFS-v4 servers that don't support mode bits are
not likely to be common in any case.
I'm not fixated on addressing this in the spec. If people think this might
infringe on their creativity in handling these issues (although when
security
is involved, unrestrained creativity has its problems), we can leave this
out. My concern is for the user. If the user has mode bits and acls on
a set of files and moves them from a brand-X NFS-v4 server to a brand-Y
NFS-v4 (or a different release of brand-X) and things stop working or work
differently, then he has his choice of cursing brand-X or brand-Y or the
NFS-v4 working group, none of which is going to do him any good. If we
all implement the same strategy, whether this is a requirement in the spec
or not, we are going to save users (and support people) a whole lot of
heartburn. I think a uniform strategy on this issue will be to the benefit
of the entire v4 community, even if the spec allows outliers to do something
else without being branded non-compliant.
> Furthermore, if there's an "additional" set of attributes (e.g., mode
bits)
> that can apply to a file, then the user has to address those attributes as
> well after setting an ACL. Although, the spec doesn't really say that
there
> won't be other attributes on a file.
Don't understand this.
> As for the wording of how ACLs are interpreted, I think the current
wording
> works pretty well.
-----Original Message-----
From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]
Sent: Wednesday, April 10, 2002 2:47 PM
To: 'beame@bws.com'; nfsv4-wg@sunroof.eng.sun.com; Khan, Saadia
Subject: RE: Interaction between mode bits and acls
Carl Beame wrote:
> On Tue Apr 09 23:47:18 2002, Khan, Saadia wrote:
> > Hi,
> >
> > I dont see anything in the spec that talks about how the mode bits and
> > acls should interact with each other if both
> > are present. I would say once an acl has been created on an object,
> > all perm checks should be done relative to
> > that and a best effort mapping should be done for the mode bits only
> > to be used as display permissions such as
> > when someone does an 'ls -l'. However there can be issues with
> > accessing files if a user sets the permissions
> > using acls and another user on a different client (without acl
> > support, can be v2/v3 client) tries to access the file
> > based on what he sees from 'ls -l'.
> >
> > The other option of keeping them both consistent with each other at
> > all times and doing permission checks using
> > both doesn;t seem very appealing and also involves extra work on the
> > part of the server.
> >
> > Any suggestions or feedback on this issue would be appreciated. What
> > are other implementations doing?
> >
> The original intention (at least what I thought it should be) was that
> the server would implement what it's own filesystem security would
> allow and then translate this to the NFS V4 ACL specification.
> I would suggest the following interpretation if the above is not true:
> 1) ACLs are scanned in order, when an entry is found which
> matches the "user" (could be the user's group etc) and explicitly
> grants or denys the access method requested, scanning stops and the
> result is returned.
Some people have brought up the case in which more than one type of
access is required by an operation. I assume that open for read-write,
for example, would fail if you don't have both read and write access.
So perhaps we need to say something like:
ACLS are scanned in order, with each entry that applies to the
requestor
(by virtue of having matching user or a group to which the requestor
belongs) being processed, until either, the processed entry denies
one of the types of access being requested, or a set of processed
entries are encountered which, taken together, allow all of the types
of requested access.
> 2) If no ACL is found which matches the "user" and the requested
> access method, the mode bits are then consulted.
What about the case in which I am asking for read and write and the
ACL allows me write? One way to handle this is to consult the mode
bits for read and write (ACL's and mode bits are alternatives), while
the other is to consult the mode bits just for read (the mode bits act
as an extension of the ACL, in that each of the three sets of bits
within the modes has an obvious mapping to an ACE, with those three
ACE's being consolted if the ACE's in the ACL proper don't resolve
the matter, and assuming that the server supports the mode attribute).
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:41 AM Z CST