Subject: RE: [nfsv4] Should owner get special previleges in the presence of acl

From: "Khan, Saadia" <[email-masked]>
Date: Mon, 21 Mar 2005 18:00:13 -0800

> -----Original Message-----
> From: Lisa Week [mailto:[email-masked]] 
> Sent: Monday, March 21, 2005 5:16 PM
> To: Khan, Saadia; [email-masked]
> Subject: Re: [nfsv4] Should owner get special previleges in 
> the presence of acl
> 
> 
> Khan, Saadia wrote:
> > If there is an acl on a file/dir, should the owner of that file/dir 
> > get any special previleges by virtue of being the owner? 
> E.g. reading 
> > and writing the acl or reading/writing the file etc.
> 
> For Solaris:
> 
> ACE4_READ_ACL and ACE4_READ_ATTRIBUTES must be set on all ALLOW ACEs.

What if I want to deny read acl access to someone?

> 
> Additionally, if the "who" field is "OWNER@", ACE4_WRITE_ACL 
> and ACE4_WRITE_ATTRIBUTES must be set on ALLOW ACEs.  Neither 
> ACE4_WRITE_ACL nor ACE4_WRITE_ATTRIBUTES may be present in an 
> ALLOW ACE with a "who" field other than "OWNER@".

What if I want to give the right to change an acl or set some attributes
to another user? This means I cant do that on a solaris server which
makes the acl model very restricted. Why doesn't the solaris server give
additional accesses to the owner? That way there wont be a need to make
the acl setting so restricted?

What about root? Does root have any special previleges?

Saadia

> 
> The other access mask bits that get allowed to the "OWNER@" are 
> completely dependent on the mode of the file.
> 
> > 
> > Currently if a file does not have an acl, I believe owner is always 
> > allowed to set the mode and group as well as read and write a file.
> 
> If a file does not have an ACL, we go by what the mode bits 
> tell us.  If 
> the mode is 177 (--x rwx rwx) the owner would still not be 
> able to read 
> and write the file until the mode is changed.
> 
> - Lisa
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Lisa Week <[email-masked]>
Date: Tue, 22 Mar 2005 10:23:32 -0700

Hi Saadia,

Comments inline.

Thanks,
Lisa

> What if I want to deny read acl access to someone?

You wouldn't be able to on our server.  Please remember that we (much 
like Linux) must play by POSIX-draft ACL rules because, currently, that 
is what is native to our server (with UFS).  Therefore, we are limited 
in what we can accept.  We can't enforce DENYing the read acl ability on 
our server, therefore we won't accept an ACL denying read acl access to 
someone.  Accepting it would mean that we made the file (or in this case 
the ACL on the file) *look* more secure than it really is.

> makes the acl model very restricted.

This is what we have to live with right now since our current underlying 
file system natively supports POSIX-draft ACLs, not NFSv4 ACLs.

> Why doesn't the solaris server give
> additional accesses to the owner?

We must honor the mode that is given to us as a result of the create() 
system call or as a result of the chmod command.  If the owner wants to 
deny themselves, read and write access on the file, we must enforce that.

If the owner doesn't initially have read and write permissions on the 
file...they can just change the ACL (or the mode) to give themselves 
permission.  Is that so bad?  What am I missing?

> That way there wont be a need to make

root trumps all.  With that said, even when someone explicity adds an 
ACE for the user "[email-masked]", we don't intercept it and modify the 
ACE to give it additional access beyond what was requested in the 
setting of the ACL.