NFS4 ACL <-> Posix ACL

NFS4 ACL <-> Posix ACL

[Alex Bremer]

Hello,

I have a working NFS4 installation (kerberos + ldap) but some trouble
understanding all these ACL mappings. On my server (ubuntu 8.04) the
ext3 filesystems are mounted with the "acl" option and setting Posix
ACLs works quite well.

On the client side (ubuntu 8.10) my libacl seems to lack NFSv4 ACL
support and therefore I can't see the acl list. However I installed
nfs4 acl tools and now I can see the ACL permissions of a
file/directory.

Using Posix ACLs on the server I added a default mask so that newly
created files/directories in the public area are group-writeable. This
works quite well on the server and this used to work with NFS3 (which
supports POSIX ACLs) on the client side, too. However on a client
using NFS4, these Posix-ACLs don't seem to get mapped to NFS4-ACLs.

Here are the ACLs:
-----------------
server> getfacl test/

user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

server> touch test/tmp
server> ls -l test/tmp
-rw-rw---- 1 albremer domusers 0 2009-03-18 18:32 test/tmp
---------------
client> nfs4_getfacl test/

A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDxtcy
A:fdi:EVERYONE@:tcy

client> touch test/tmp
client> ls -l test/tmp
-rw-r----- 1 albremer domusers 0 2009-03-18 18:32 test/tmp
---------------

Can anybody tell me what is wrong here? Is there any mapping between
NFS4-ACLs and Posix-ACLs on the server side or are they handled
seperately?

Another question: If I add the mount option "user_xattr" to the nfs4
exported filesystems, on the client side all permissions are shown as
"nobody:nogroup". Why is that?

Alex

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Wed, Mar 18, 2009 at 06:42:10PM +0100, Alex Bremer wrote:
> Hello,
> 
> I have a working NFS4 installation (kerberos + ldap) but some trouble
> understanding all these ACL mappings. On my server (ubuntu 8.04) the
> ext3 filesystems are mounted with the "acl" option and setting Posix
> ACLs works quite well.
> 
> On the client side (ubuntu 8.10) my libacl seems to lack NFSv4 ACL
> support and therefore I can't see the acl list. However I installed
> nfs4 acl tools and now I can see the ACL permissions of a
> file/directory.
> 
> Using Posix ACLs on the server I added a default mask so that newly
> created files/directories in the public area are group-writeable. This
> works quite well on the server and this used to work with NFS3 (which
> supports POSIX ACLs) on the client side, too. However on a client
> using NFS4, these Posix-ACLs don't seem to get mapped to NFS4-ACLs.

Actually, they do; what's happening (I believe--this is partly just
memory based on last time I looked at something like this) is more
subtle: the umask is being overridden by inheritance in the v2/v3 case,
and not in the v4 case.

Posix default acls are supposed to override the umask.  This is tricky
for NFS, since the umask isn't sent over the wire on file creation,
leaving the client and server no way to distinguish the create mode from
the umask.  The v2/v3 client currently works around this by doing the
whole inheritance calculation on the client (reading the directory's
acl, then explicitly setting the new child's acl based on it).  The v4
client doesn't do that.  So:

> Here are the ACLs:
> -----------------
> server> getfacl test/
> 
> user::rwx
> group::rwx
> other::---
> default:user::rwx
> default:group::rwx
> default:other::---
> 
> server> touch test/tmp
> server> ls -l test/tmp
> -rw-rw---- 1 albremer domusers 0 2009-03-18 18:32 test/tmp
> ---------------
> client> nfs4_getfacl test/
> 
> A::OWNER@:rwaDxtTcCy
> A::GROUP@:rwaDxtcy
> A::EVERYONE@:tcy
> A:fdi:OWNER@:rwaDxtTcCy
> A:fdi:GROUP@:rwaDxtcy
> A:fdi:EVERYONE@:tcy
> 
> client> touch test/tmp
> client> ls -l test/tmp
> -rw-r----- 1 albremer domusers 0 2009-03-18 18:32 test/tmp
> ---------------

If you do a getfacl on the server you'll probably see that it looks
like:

# file: test/tmp
# owner: root
# group: root
user::rw-
group::rwx                      #effective:r--
mask::r--
other::---

So note the "group" bits are set correctly, but the mask is limiting
permissions as a result of the open that created the file setting the
file to 644 (based on a 022 umask).

> Can anybody tell me what is wrong here? Is there any mapping between
> NFS4-ACLs and Posix-ACLs on the server side or are they handled
> seperately?

There are no nfsv4 acls on the filesystem at all, so everything is done
by mapping to and from the filesystem's posix acls.

> Another question: If I add the mount option "user_xattr" to the nfs4
> exported filesystems, on the client side all permissions are shown as
> "nobody:nogroup". Why is that?

That's bizarre.  Neither server nor client nor idmapd should be using
user extended attributes at all.  Are you sure you something else wasn't
changed at the same time?

--b.

Re: NFS4 ACL <-> Posix ACL

[Alex Bremer]

2009/3/19, J. Bruce Fields <bfields@fieldses.org>:
> On Wed, Mar 18, 2009 at 06:42:10PM +0100, Alex Bremer wrote:
>> However on a client
>> using NFS4, these Posix-ACLs don't seem to get mapped to NFS4-ACLs.
>
> Actually, they do; what's happening (I believe--this is partly just
> memory based on last time I looked at something like this) is more
> subtle: the umask is being overridden by inheritance in the v2/v3 case,
> and not in the v4 case.
>
> Posix default acls are supposed to override the umask.  This is tricky
> for NFS, since the umask isn't sent over the wire on file creation,
> leaving the client and server no way to distinguish the create mode from
> the umask.  The v2/v3 client currently works around this by doing the
> whole inheritance calculation on the client (reading the directory's
> acl, then explicitly setting the new child's acl based on it).  The v4
> client doesn't do that.  So:

So is there any way to make newly created files group writeable except
for setting the umask of each user to 002? Setting the umask to 002 is
not an option for us, but all files in the public area have to be
group writeable. Is there maybe a mount option to set the umask or a
server sided option which enforces the group writeable flag?

I would expect that my use case is not that uncommon and that many
companys have the exact same problem. Would the inheritance work if we
used a fully NFS4-ACL compatible filesystem? Is there any for Linux?
How do other people share public files with NFS4? If there is no other
way than setting the users's umask to 002, this would practically
limit the use of NFS4 to private shares like home directories. I can't
tell my users to change the permissions after creating a file. Some of
them do not even know what permissions are.

> There are no nfsv4 acls on the filesystem at all, so everything is done
> by mapping to and from the filesystem's posix acls.

So I guess there is no NFS4-ACL compliant filesystem for linux either? :-(

>> Another question: If I add the mount option "user_xattr" to the nfs4
>> exported filesystems, on the client side all permissions are shown as
>> "nobody:nogroup". Why is that?
>
> That's bizarre.  Neither server nor client nor idmapd should be using
> user extended attributes at all.  Are you sure you something else wasn't
> changed at the same time?

Oh, you are right. I just gave it another try and now it works. Don't
know what happened. Last time I tried it, the only thing I changed was
the user_xattr mount option and I got all owner:group entries as
nobody:nogroup. I changed the flag back and it worked again. Now it
even works with user_xattr on.

Alex

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Mon, Mar 23, 2009 at 02:46:46PM +0100, Alex Bremer wrote:
> 2009/3/19, J. Bruce Fields <bfields@fieldses.org>:
> > On Wed, Mar 18, 2009 at 06:42:10PM +0100, Alex Bremer wrote:
> >> However on a client
> >> using NFS4, these Posix-ACLs don't seem to get mapped to NFS4-ACLs.
> >
> > Actually, they do; what's happening (I believe--this is partly just
> > memory based on last time I looked at something like this) is more
> > subtle: the umask is being overridden by inheritance in the v2/v3 case,
> > and not in the v4 case.
> >
> > Posix default acls are supposed to override the umask.  This is tricky
> > for NFS, since the umask isn't sent over the wire on file creation,
> > leaving the client and server no way to distinguish the create mode from
> > the umask.  The v2/v3 client currently works around this by doing the
> > whole inheritance calculation on the client (reading the directory's
> > acl, then explicitly setting the new child's acl based on it).  The v4
> > client doesn't do that.  So:
> 
> So is there any way to make newly created files group writeable except
> for setting the umask of each user to 002?

I think that's the only option.

And that looks hard to fix; if we were going to implement the same
"inheritance overrides umask" exception as we do for posix acls, either:

	- The server would have to know about the umask; this would
	  require a protocol change.  (But it might not be that hard;
	  you could have a write-only "set the mode to this, but only in
	  the absence of inheritance" attribute.)
	- The client would have to do the inheritance itself, as it does
	  with posix acls.  This is perhaps not impossible, but it's
	  much more complicated with v4 acls.

Hm.  Another odd option: do the open with the create mode + umask, as we
currently do, then do a subsequent setattr to the create mode if the
create mode is more generous and if the client detects inheritable acls
on the parent directory.

> Setting the umask to 002 is
> not an option for us, but all files in the public area have to be
> group writeable. Is there maybe a mount option to set the umask or a
> server sided option which enforces the group writeable flag?
> 
> I would expect that my use case is not that uncommon and that many
> companys have the exact same problem. Would the inheritance work if we
> used a fully NFS4-ACL compatible filesystem?

No, and I suspect non-linux servers all have similar behavior in this
respect.

> Is there any for Linux?

Not currently.

> How do other people share public files with NFS4? If there is no other
> way than setting the users's umask to 002, this would practically
> limit the use of NFS4 to private shares like home directories.

I don't understand why--can't you use the user-private-group trick?:

	http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-users-groups-private-groups.html

--b.

Re: NFS4 ACL <-> Posix ACL

[Alex Bremer]

2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
>> So is there any way to make newly created files group writeable except
>> for setting the umask of each user to 002?
>
> I think that's the only option.
>
> And that looks hard to fix; if we were going to implement the same
> "inheritance overrides umask" exception as we do for posix acls, either:
>
> 	- The server would have to know about the umask; this would
> 	  require a protocol change.  (But it might not be that hard;
> 	  you could have a write-only "set the mode to this, but only in
> 	  the absence of inheritance" attribute.)
> 	- The client would have to do the inheritance itself, as it does
> 	  with posix acls.  This is perhaps not impossible, but it's
> 	  much more complicated with v4 acls.
>
> Hm.  Another odd option: do the open with the create mode + umask, as we
> currently do, then do a subsequent setattr to the create mode if the
> create mode is more generous and if the client detects inheritable acls
> on the parent directory.

Why so complicated? Of course these options would be the nicest way to
do it as it allows to set different permission inheritances on each
directory. However for many use cases it would be enough if one could
set the permissions on a share basis. A simple umask mount-option
would already help a lot. This way administrators could enforce a
umask on a share.

One of the problems with setting a global umask on a user basis is
that it can be override very easily. If a user doesn't like the fact
that all files are group writeable he can easily change it and then he
usually forgets to set write-permissions manually when writing public
files. As a consequence other users who want to write that file come
to me to have the permissions reset as they can not even tell who is
the owner of the file and ask him. :-)

>> Setting the umask to 002 is
>> not an option for us, but all files in the public area have to be
>> group writeable. Is there maybe a mount option to set the umask or a
>> server sided option which enforces the group writeable flag?
>>
>> I would expect that my use case is not that uncommon and that many
>> companys have the exact same problem. Would the inheritance work if we
>> used a fully NFS4-ACL compatible filesystem?
>
> No, and I suspect non-linux servers all have similar behavior in this
> respect.

Unix servery yes, but on windows using NTFS you can inherit permissions.

With PosixACLs Unix finally got permission inheritance too and this is
a blessing for administrators. The normal unix filesystem permissions
are good enough for many use cases but in a company with many users
and many different groups they do not fit. The simple case of allowing
users of two different groups access to a directory without giving
others rx access forces you to create a third group with all the users
of both groups. Adding new users gets a pain in the ass as you have to
add them to more and more groups just to get the permissions right.

So Posix ACLs are really great for admins. From an admin's point of
view I can't understand why the NFS4-ACLs - which are actually
supperior to PosixACLs - still depend on the user's umask. I
understand the problems you have from a programmers point of view but
if I set a d:group:mask on a directory I expect that these permissions
get inherited on the client side, too - like it was with NFS3+ACL.

Don't understand me wrong: I don't want to flame here - I appritiate
your work and I love NFS as it is damn fast. I just want to show you
what an admin's expectation is. People who use PosixACLs are used to
inheritance (if they set a default group or mask), windows people are
used to it anyway and nobody would expect that when using NFS4 it all
comes down to the user's umask settings. Especially as it was already
working with NFS3. I know that NFS3+ACL is a totally different topic
then NFS4+ACL but many user's won't care - especially as they do not
have any advantage from NFS4ACLs as they are mapped to PosixACLs
anyway.

I really hate the security risks I have to take for NFS3 but in my
case I guess I have to revert the public shares back to NFS3. It would
be really great if you could think about implementing a umask
mount-option to allow enforced share based umask settings.


>> How do other people share public files with NFS4? If there is no other
>> way than setting the users's umask to 002, this would practically
>> limit the use of NFS4 to private shares like home directories.
>
> I don't understand why--can't you use the user-private-group trick?:

- umask setting can be overriden easily - see above
- we actually have directories where files should only be group readable.

Alex

Re: NFS4 ACL <-> Posix ACL

[Greg Banks]

Alex Bremer wrote:
> [...]
>  Would the inheritance work if we
> used a fully NFS4-ACL compatible filesystem? Is there any for Linux?
>   

There are patches to make ext3 and XFS natively NFSv4 ACL aware.  The
XFS patches have been shipping in an SGI product for some months now.

http://oss.sgi.com/projects/nfs/nfs4acl/

I believe GPFS2 from IBM has native NFSv4 ACL support too.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

Re: NFS4 ACL <-> Posix ACL

[Alex Bremer]

2009/3/24, Greg Banks <gnb@sgi.com>:
> Alex Bremer wrote:
>> [...]
>>  Would the inheritance work if we
>> used a fully NFS4-ACL compatible filesystem? Is there any for Linux?
>>
>
> There are patches to make ext3 and XFS natively NFSv4 ACL aware.  The
> XFS patches have been shipping in an SGI product for some months now.
>
> http://oss.sgi.com/projects/nfs/nfs4acl/
>

Thanks for that link. I will have a closer look at it.

But if I understood J. Bruce Fields correctly an NFS4-ACL compliant
filesystem wouldn't fix the inheritance problem, too because either
the server has to know the umask or the client has to lookup the
directory ACLs. So there would be no real advantage of using NFS4-ACLs
- most things can be done with PosixACLs.

I really begin to hate these umask settings. From my point of view
these settings should only be used as a last resort fallback.
Filesystem inheritance ACLs should always have precedence.

Alex

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> 2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
> >> So is there any way to make newly created files group writeable except
> >> for setting the umask of each user to 002?
> >
> > I think that's the only option.
> >
> > And that looks hard to fix; if we were going to implement the same
> > "inheritance overrides umask" exception as we do for posix acls, either:
> >
> > 	- The server would have to know about the umask; this would
> > 	  require a protocol change.  (But it might not be that hard;
> > 	  you could have a write-only "set the mode to this, but only in
> > 	  the absence of inheritance" attribute.)
> > 	- The client would have to do the inheritance itself, as it does
> > 	  with posix acls.  This is perhaps not impossible, but it's
> > 	  much more complicated with v4 acls.
> >
> > Hm.  Another odd option: do the open with the create mode + umask, as we
> > currently do, then do a subsequent setattr to the create mode if the
> > create mode is more generous and if the client detects inheritable acls
> > on the parent directory.
> 
> Why so complicated? Of course these options would be the nicest way to
> do it as it allows to set different permission inheritances on each
> directory. However for many use cases it would be enough if one could
> set the permissions on a share basis. A simple umask mount-option
> would already help a lot. This way administrators could enforce a
> umask on a share.

I don't know what to think of a umask mount option.  That's a question
for Trond.

> One of the problems with setting a global umask on a user basis is
> that it can be override very easily. If a user doesn't like the fact
> that all files are group writeable he can easily change it and then he
> usually forgets to set write-permissions manually when writing public
> files. As a consequence other users who want to write that file come
> to me to have the permissions reset as they can not even tell who is
> the owner of the file and ask him. :-)
> 
> >> Setting the umask to 002 is
> >> not an option for us, but all files in the public area have to be
> >> group writeable. Is there maybe a mount option to set the umask or a
> >> server sided option which enforces the group writeable flag?
> >>
> >> I would expect that my use case is not that uncommon and that many
> >> companys have the exact same problem. Would the inheritance work if we
> >> used a fully NFS4-ACL compatible filesystem?
> >
> > No, and I suspect non-linux servers all have similar behavior in this
> > respect.
> 
> Unix servery yes, but on windows using NTFS you can inherit permissions.
> 
> With PosixACLs Unix finally got permission inheritance too and this is
> a blessing for administrators. The normal unix filesystem permissions
> are good enough for many use cases but in a company with many users
> and many different groups they do not fit. The simple case of allowing
> users of two different groups access to a directory without giving
> others rx access forces you to create a third group with all the users
> of both groups. Adding new users gets a pain in the ass as you have to
> add them to more and more groups just to get the permissions right.
> 
> So Posix ACLs are really great for admins. From an admin's point of
> view I can't understand why the NFS4-ACLs - which are actually
> supperior to PosixACLs - still depend on the user's umask. I
> understand the problems you have from a programmers point of view but
> if I set a d:group:mask on a directory I expect that these permissions
> get inherited on the client side, too - like it was with NFS3+ACL.
> 
> Don't understand me wrong: I don't want to flame here - I appritiate
> your work and I love NFS as it is damn fast. I just want to show you
> what an admin's expectation is. People who use PosixACLs are used to
> inheritance (if they set a default group or mask), windows people are
> used to it anyway and nobody would expect that when using NFS4 it all
> comes down to the user's umask settings. Especially as it was already
> working with NFS3. I know that NFS3+ACL is a totally different topic
> then NFS4+ACL but many user's won't care - especially as they do not
> have any advantage from NFS4ACLs as they are mapped to PosixACLs
> anyway.

I appreciate the problem--if nothing else this is a subtle change that
other admins will also hit, and that will be hard for them to diagnose.

I just don't see a really good solution.

> I really hate the security risks I have to take for NFS3
 
Are you aware that rpcsec_gss/krb5 still works for v3?

There are a few holes left (sideband protocols, notably mount, still use
auth_sys), but it might be enough for your purposes.

> but in my
> case I guess I have to revert the public shares back to NFS3. It would
> be really great if you could think about implementing a umask
> mount-option to allow enforced share based umask settings.
> 
> 
> >> How do other people share public files with NFS4? If there is no other
> >> way than setting the users's umask to 002, this would practically
> >> limit the use of NFS4 to private shares like home directories.
> >
> > I don't understand why--can't you use the user-private-group trick?:
> 
> - umask setting can be overriden easily - see above

I'm surprised people fool with their umasks that much, but OK.

> - we actually have directories where files should only be group readable.

I don't get it--why not set an inheritable acl on those directories that
permits only read to the group?

--b.

Re: NFS4 ACL <-> Posix ACL

[Trond Myklebust]

On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > 2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
> > >> So is there any way to make newly created files group writeable except
> > >> for setting the umask of each user to 002?
> > >
> > > I think that's the only option.
> > >
> > > And that looks hard to fix; if we were going to implement the same
> > > "inheritance overrides umask" exception as we do for posix acls, either:
> > >
> > > 	- The server would have to know about the umask; this would
> > > 	  require a protocol change.  (But it might not be that hard;
> > > 	  you could have a write-only "set the mode to this, but only in
> > > 	  the absence of inheritance" attribute.)
> > > 	- The client would have to do the inheritance itself, as it does
> > > 	  with posix acls.  This is perhaps not impossible, but it's
> > > 	  much more complicated with v4 acls.
> > >
> > > Hm.  Another odd option: do the open with the create mode + umask, as we
> > > currently do, then do a subsequent setattr to the create mode if the
> > > create mode is more generous and if the client detects inheritable acls
> > > on the parent directory.
> > 
> > Why so complicated? Of course these options would be the nicest way to
> > do it as it allows to set different permission inheritances on each
> > directory. However for many use cases it would be enough if one could
> > set the permissions on a share basis. A simple umask mount-option
> > would already help a lot. This way administrators could enforce a
> > umask on a share.
> 
> I don't know what to think of a umask mount option.  That's a question
> for Trond.

Ugh, no. We already have too many mount options, and this suggestion
doesn't even fix any problems.

The correct thing to do is to check for acl support on the server, and
then check directories for inheritance aces before we decide to create a
file.
The existing 'noacl' mount option could then turn off this type of check
in cases where the administrator doesn't care to follow inheritance
rules...

> > One of the problems with setting a global umask on a user basis is
> > that it can be override very easily. If a user doesn't like the fact
> > that all files are group writeable he can easily change it and then he
> > usually forgets to set write-permissions manually when writing public
> > files. As a consequence other users who want to write that file come
> > to me to have the permissions reset as they can not even tell who is
> > the owner of the file and ask him. :-)
> > 
> > >> Setting the umask to 002 is
> > >> not an option for us, but all files in the public area have to be
> > >> group writeable. Is there maybe a mount option to set the umask or a
> > >> server sided option which enforces the group writeable flag?
> > >>
> > >> I would expect that my use case is not that uncommon and that many
> > >> companys have the exact same problem. Would the inheritance work if we
> > >> used a fully NFS4-ACL compatible filesystem?
> > >
> > > No, and I suspect non-linux servers all have similar behavior in this
> > > respect.
> > 
> > Unix servery yes, but on windows using NTFS you can inherit permissions.
> > 
> > With PosixACLs Unix finally got permission inheritance too and this is
> > a blessing for administrators. The normal unix filesystem permissions
> > are good enough for many use cases but in a company with many users
> > and many different groups they do not fit. The simple case of allowing
> > users of two different groups access to a directory without giving
> > others rx access forces you to create a third group with all the users
> > of both groups. Adding new users gets a pain in the ass as you have to
> > add them to more and more groups just to get the permissions right.
> > 
> > So Posix ACLs are really great for admins. From an admin's point of
> > view I can't understand why the NFS4-ACLs - which are actually
> > supperior to PosixACLs - still depend on the user's umask. I
> > understand the problems you have from a programmers point of view but
> > if I set a d:group:mask on a directory I expect that these permissions
> > get inherited on the client side, too - like it was with NFS3+ACL.
> > 
> > Don't understand me wrong: I don't want to flame here - I appritiate
> > your work and I love NFS as it is damn fast. I just want to show you
> > what an admin's expectation is. People who use PosixACLs are used to
> > inheritance (if they set a default group or mask), windows people are
> > used to it anyway and nobody would expect that when using NFS4 it all
> > comes down to the user's umask settings. Especially as it was already
> > working with NFS3. I know that NFS3+ACL is a totally different topic
> > then NFS4+ACL but many user's won't care - especially as they do not
> > have any advantage from NFS4ACLs as they are mapped to PosixACLs
> > anyway.
> 
> I appreciate the problem--if nothing else this is a subtle change that
> other admins will also hit, and that will be hard for them to diagnose.
> 
> I just don't see a really good solution.
> 
> > I really hate the security risks I have to take for NFS3
>  
> Are you aware that rpcsec_gss/krb5 still works for v3?
> 
> There are a few holes left (sideband protocols, notably mount, still use
> auth_sys), but it might be enough for your purposes.
> 
> > but in my
> > case I guess I have to revert the public shares back to NFS3. It would
> > be really great if you could think about implementing a umask
> > mount-option to allow enforced share based umask settings.
> > 
> > 
> > >> How do other people share public files with NFS4? If there is no other
> > >> way than setting the users's umask to 002, this would practically
> > >> limit the use of NFS4 to private shares like home directories.
> > >
> > > I don't understand why--can't you use the user-private-group trick?:
> > 
> > - umask setting can be overriden easily - see above
> 
> I'm surprised people fool with their umasks that much, but OK.
> 
> > - we actually have directories where files should only be group readable.
> 
> I don't get it--why not set an inheritable acl on those directories that
> permits only read to the group?

That only works if the client actually respects the acl...

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > >> How do other people share public files with NFS4? If there is no other
> > > >> way than setting the users's umask to 002, this would practically
> > > >> limit the use of NFS4 to private shares like home directories.
> > > >
> > > > I don't understand why--can't you use the user-private-group trick?:
...
> > > - we actually have directories where files should only be group readable.
> > 
> > I don't get it--why not set an inheritable acl on those directories that
> > permits only read to the group?
> 
> That only works if the client actually respects the acl...

I don't understand.  ACL enforcement and inheritance are both done on
the server side.

The problem is just that the umask is applied on the client side.  But
if the umask is 002, and an inheritable ACL permits only read, then the
result of inheritance and umask-application will be an ACL that permits
reads (and only reads) to the group owner (and to any named users and
groups).

--b.

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > 2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
> > > >> So is there any way to make newly created files group writeable except
> > > >> for setting the umask of each user to 002?
> > > >
> > > > I think that's the only option.
> > > >
> > > > And that looks hard to fix; if we were going to implement the same
> > > > "inheritance overrides umask" exception as we do for posix acls, either:
> > > >
> > > > 	- The server would have to know about the umask; this would
> > > > 	  require a protocol change.  (But it might not be that hard;
> > > > 	  you could have a write-only "set the mode to this, but only in
> > > > 	  the absence of inheritance" attribute.)
> > > > 	- The client would have to do the inheritance itself, as it does
> > > > 	  with posix acls.  This is perhaps not impossible, but it's
> > > > 	  much more complicated with v4 acls.
> > > >
> > > > Hm.  Another odd option: do the open with the create mode + umask, as we
> > > > currently do, then do a subsequent setattr to the create mode if the
> > > > create mode is more generous and if the client detects inheritable acls
> > > > on the parent directory.
> > > 
> > > Why so complicated? Of course these options would be the nicest way to
> > > do it as it allows to set different permission inheritances on each
> > > directory. However for many use cases it would be enough if one could
> > > set the permissions on a share basis. A simple umask mount-option
> > > would already help a lot. This way administrators could enforce a
> > > umask on a share.
> > 
> > I don't know what to think of a umask mount option.  That's a question
> > for Trond.
> 
> Ugh, no. We already have too many mount options, and this suggestion
> doesn't even fix any problems.
> 
> The correct thing to do is to check for acl support on the server, and
> then check directories for inheritance aces before we decide to create a
> file.

OK, so if we find an inheritable ace on the file, then we just skip
sending the umask in the mode that's sent on open.

The only objection I could see also applies to the current posix code:
there's a small race allowing the file create to be done with stale
information from the parent directory.

> The existing 'noacl' mount option could then turn off this type of check
> in cases where the administrator doesn't care to follow inheritance
> rules...

OK.

For now this falls into the category of patches I'd happily shepherd
along if someone else would write them.  Shouldn't be too hard to write
though.

--b.

Re: NFS4 ACL <-> Posix ACL

[Trond Myklebust]

On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > >> How do other people share public files with NFS4? If there is no other
> > > > >> way than setting the users's umask to 002, this would practically
> > > > >> limit the use of NFS4 to private shares like home directories.
> > > > >
> > > > > I don't understand why--can't you use the user-private-group trick?:
> ...
> > > > - we actually have directories where files should only be group readable.
> > > 
> > > I don't get it--why not set an inheritable acl on those directories that
> > > permits only read to the group?
> > 
> > That only works if the client actually respects the acl...
> 
> I don't understand.  ACL enforcement and inheritance are both done on
> the server side.
> 
> The problem is just that the umask is applied on the client side.  But
> if the umask is 002, and an inheritable ACL permits only read, then the
> result of inheritance and umask-application will be an ACL that permits
> reads (and only reads) to the group owner (and to any named users and
> groups).

The client currently always sends a mode. My interpretation of RFC3530
is that this will always override the inherited ACL (see the discussion
in OP_OPEN and OP_CREATE w.r.t. the createattrs field).

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFS4 ACL <-> Posix ACL

[Trond Myklebust]

On Tue, 2009-03-24 at 18:21 -0400, J. Bruce Fields wrote:
> On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > 2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
> > > > >> So is there any way to make newly created files group writeable except
> > > > >> for setting the umask of each user to 002?
> > > > >
> > > > > I think that's the only option.
> > > > >
> > > > > And that looks hard to fix; if we were going to implement the same
> > > > > "inheritance overrides umask" exception as we do for posix acls, either:
> > > > >
> > > > > 	- The server would have to know about the umask; this would
> > > > > 	  require a protocol change.  (But it might not be that hard;
> > > > > 	  you could have a write-only "set the mode to this, but only in
> > > > > 	  the absence of inheritance" attribute.)
> > > > > 	- The client would have to do the inheritance itself, as it does
> > > > > 	  with posix acls.  This is perhaps not impossible, but it's
> > > > > 	  much more complicated with v4 acls.
> > > > >
> > > > > Hm.  Another odd option: do the open with the create mode + umask, as we
> > > > > currently do, then do a subsequent setattr to the create mode if the
> > > > > create mode is more generous and if the client detects inheritable acls
> > > > > on the parent directory.
> > > > 
> > > > Why so complicated? Of course these options would be the nicest way to
> > > > do it as it allows to set different permission inheritances on each
> > > > directory. However for many use cases it would be enough if one could
> > > > set the permissions on a share basis. A simple umask mount-option
> > > > would already help a lot. This way administrators could enforce a
> > > > umask on a share.
> > > 
> > > I don't know what to think of a umask mount option.  That's a question
> > > for Trond.
> > 
> > Ugh, no. We already have too many mount options, and this suggestion
> > doesn't even fix any problems.
> > 
> > The correct thing to do is to check for acl support on the server, and
> > then check directories for inheritance aces before we decide to create a
> > file.
> 
> OK, so if we find an inheritable ace on the file, then we just skip
> sending the umask in the mode that's sent on open.

No. That would violate the spec. I meant that the client needs to check
if the server supports acls, and then needs to check those acls on the
directory in which it wants to create the file.

In order to avoid any races, it probably needs to send the inherited ACL
in the createattrs field. Otherwise, if a user were to remove the
inherited ACL before the client sends the OPEN/CREATE, then the server
would no longer have an ACL to set on the file...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 06:22:47PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > >> How do other people share public files with NFS4? If there is no other
> > > > > >> way than setting the users's umask to 002, this would practically
> > > > > >> limit the use of NFS4 to private shares like home directories.
> > > > > >
> > > > > > I don't understand why--can't you use the user-private-group trick?:
> > ...
> > > > > - we actually have directories where files should only be group readable.
> > > > 
> > > > I don't get it--why not set an inheritable acl on those directories that
> > > > permits only read to the group?
> > > 
> > > That only works if the client actually respects the acl...
> > 
> > I don't understand.  ACL enforcement and inheritance are both done on
> > the server side.
> > 
> > The problem is just that the umask is applied on the client side.  But
> > if the umask is 002, and an inheritable ACL permits only read, then the
> > result of inheritance and umask-application will be an ACL that permits
> > reads (and only reads) to the group owner (and to any named users and
> > groups).
> 
> The client currently always sends a mode. My interpretation of RFC3530
> is that this will always override the inherited ACL (see the discussion
> in OP_OPEN and OP_CREATE w.r.t. the createattrs field).

Depends on what you mean by "override".  It shouldn't be replacing the
inherited ACL wholesale; see 6.4.3.

And I don't think we'd want to *entirely* stop sending the mode.

With POSIX ACLs the compromise is to ignore the umask, but continue to
respect the creat()/open() mode.

--b.

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 06:28:06PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 18:21 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > 2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
> > > > > >> So is there any way to make newly created files group writeable except
> > > > > >> for setting the umask of each user to 002?
> > > > > >
> > > > > > I think that's the only option.
> > > > > >
> > > > > > And that looks hard to fix; if we were going to implement the same
> > > > > > "inheritance overrides umask" exception as we do for posix acls, either:
> > > > > >
> > > > > > 	- The server would have to know about the umask; this would
> > > > > > 	  require a protocol change.  (But it might not be that hard;
> > > > > > 	  you could have a write-only "set the mode to this, but only in
> > > > > > 	  the absence of inheritance" attribute.)
> > > > > > 	- The client would have to do the inheritance itself, as it does
> > > > > > 	  with posix acls.  This is perhaps not impossible, but it's
> > > > > > 	  much more complicated with v4 acls.
> > > > > >
> > > > > > Hm.  Another odd option: do the open with the create mode + umask, as we
> > > > > > currently do, then do a subsequent setattr to the create mode if the
> > > > > > create mode is more generous and if the client detects inheritable acls
> > > > > > on the parent directory.
> > > > > 
> > > > > Why so complicated? Of course these options would be the nicest way to
> > > > > do it as it allows to set different permission inheritances on each
> > > > > directory. However for many use cases it would be enough if one could
> > > > > set the permissions on a share basis. A simple umask mount-option
> > > > > would already help a lot. This way administrators could enforce a
> > > > > umask on a share.
> > > > 
> > > > I don't know what to think of a umask mount option.  That's a question
> > > > for Trond.
> > > 
> > > Ugh, no. We already have too many mount options, and this suggestion
> > > doesn't even fix any problems.
> > > 
> > > The correct thing to do is to check for acl support on the server, and
> > > then check directories for inheritance aces before we decide to create a
> > > file.
> > 
> > OK, so if we find an inheritable ace on the file, then we just skip
> > sending the umask in the mode that's sent on open.

Sorry, I meant "the inheritable ace on the parent directory" in the
above.

> No. That would violate the spec. I meant that the client needs to check
> if the server supports acls, and then needs to check those acls on the
> directory in which it wants to create the file.
> 
> In order to avoid any races, it probably needs to send the inherited ACL
> in the createattrs field. Otherwise, if a user were to remove the
> inherited ACL before the client sends the OPEN/CREATE, then the server
> would no longer have an ACL to set on the file...

Either that, or send the umask-less mode and let the server do the
inheritance calculation.

--b.

Re: NFS4 ACL <-> Posix ACL

[Trond Myklebust]

On Tue, 2009-03-24 at 18:34 -0400, J. Bruce Fields wrote:
> On Tue, Mar 24, 2009 at 06:22:47PM -0400, Trond Myklebust wrote:
> > On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> > > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > > >> How do other people share public files with NFS4? If there is no other
> > > > > > >> way than setting the users's umask to 002, this would practically
> > > > > > >> limit the use of NFS4 to private shares like home directories.
> > > > > > >
> > > > > > > I don't understand why--can't you use the user-private-group trick?:
> > > ...
> > > > > > - we actually have directories where files should only be group readable.
> > > > > 
> > > > > I don't get it--why not set an inheritable acl on those directories that
> > > > > permits only read to the group?
> > > > 
> > > > That only works if the client actually respects the acl...
> > > 
> > > I don't understand.  ACL enforcement and inheritance are both done on
> > > the server side.
> > > 
> > > The problem is just that the umask is applied on the client side.  But
> > > if the umask is 002, and an inheritable ACL permits only read, then the
> > > result of inheritance and umask-application will be an ACL that permits
> > > reads (and only reads) to the group owner (and to any named users and
> > > groups).
> > 
> > The client currently always sends a mode. My interpretation of RFC3530
> > is that this will always override the inherited ACL (see the discussion
> > in OP_OPEN and OP_CREATE w.r.t. the createattrs field).
> 
> Depends on what you mean by "override".  It shouldn't be replacing the
> inherited ACL wholesale; see 6.4.3.

That is the v4.1 draft, which is hardly normative for NFSv4.0 servers.
Note, however, that in the v4.1 case too, the server is required to
replace the OWNER@, GROUP@ and EVERYONE@ fields when the client sends a
mode attribute (afaics from 6.4.1.1).

Note also that there is no fancy "mode_set_masked" attribute in NFSv4.0,
so we don't have an alternative to sending the full mode attribute...

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 06:54:41PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 18:34 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 06:22:47PM -0400, Trond Myklebust wrote:
> > > On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> > > > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > > > >> How do other people share public files with NFS4? If there is no other
> > > > > > > >> way than setting the users's umask to 002, this would practically
> > > > > > > >> limit the use of NFS4 to private shares like home directories.
> > > > > > > >
> > > > > > > > I don't understand why--can't you use the user-private-group trick?:
> > > > ...
> > > > > > > - we actually have directories where files should only be group readable.
> > > > > > 
> > > > > > I don't get it--why not set an inheritable acl on those directories that
> > > > > > permits only read to the group?
> > > > > 
> > > > > That only works if the client actually respects the acl...
> > > > 
> > > > I don't understand.  ACL enforcement and inheritance are both done on
> > > > the server side.
> > > > 
> > > > The problem is just that the umask is applied on the client side.  But
> > > > if the umask is 002, and an inheritable ACL permits only read, then the
> > > > result of inheritance and umask-application will be an ACL that permits
> > > > reads (and only reads) to the group owner (and to any named users and
> > > > groups).
> > > 
> > > The client currently always sends a mode. My interpretation of RFC3530
> > > is that this will always override the inherited ACL (see the discussion
> > > in OP_OPEN and OP_CREATE w.r.t. the createattrs field).
> > 
> > Depends on what you mean by "override".  It shouldn't be replacing the
> > inherited ACL wholesale; see 6.4.3.
> 
> That is the v4.1 draft, which is hardly normative for NFSv4.0 servers.
> Note, however, that in the v4.1 case too, the server is required to
> replace the OWNER@, GROUP@ and EVERYONE@ fields when the client sends a
> mode attribute (afaics from 6.4.1.1).

Sure, but there's no need to blow away ACEs for named users and
groups--anyone that cares about posix should be restricting them to
grant no more than the mode group bits, but that's all.

> 
> Note also that there is no fancy "mode_set_masked" attribute in NFSv4.0,
> so we don't have an alternative to sending the full mode attribute...

Understood.

--b.

Re: NFS4 ACL <-> Posix ACL

[Trond Myklebust]

On Tue, 2009-03-24 at 19:02 -0400, J. Bruce Fields wrote:
> On Tue, Mar 24, 2009 at 06:54:41PM -0400, Trond Myklebust wrote:
> > On Tue, 2009-03-24 at 18:34 -0400, J. Bruce Fields wrote:
> > > On Tue, Mar 24, 2009 at 06:22:47PM -0400, Trond Myklebust wrote:
> > > > On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> > > > > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > > > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > > > > >> How do other people share public files with NFS4? If there is no other
> > > > > > > > >> way than setting the users's umask to 002, this would practically
> > > > > > > > >> limit the use of NFS4 to private shares like home directories.
> > > > > > > > >
> > > > > > > > > I don't understand why--can't you use the user-private-group trick?:
> > > > > ...
> > > > > > > > - we actually have directories where files should only be group readable.
> > > > > > > 
> > > > > > > I don't get it--why not set an inheritable acl on those directories that
> > > > > > > permits only read to the group?
> > > > > > 
> > > > > > That only works if the client actually respects the acl...
> > > > > 
> > > > > I don't understand.  ACL enforcement and inheritance are both done on
> > > > > the server side.
> > > > > 
> > > > > The problem is just that the umask is applied on the client side.  But
> > > > > if the umask is 002, and an inheritable ACL permits only read, then the
> > > > > result of inheritance and umask-application will be an ACL that permits
> > > > > reads (and only reads) to the group owner (and to any named users and
> > > > > groups).
> > > > 
> > > > The client currently always sends a mode. My interpretation of RFC3530
> > > > is that this will always override the inherited ACL (see the discussion
> > > > in OP_OPEN and OP_CREATE w.r.t. the createattrs field).
> > > 
> > > Depends on what you mean by "override".  It shouldn't be replacing the
> > > inherited ACL wholesale; see 6.4.3.
> > 
> > That is the v4.1 draft, which is hardly normative for NFSv4.0 servers.
> > Note, however, that in the v4.1 case too, the server is required to
> > replace the OWNER@, GROUP@ and EVERYONE@ fields when the client sends a
> > mode attribute (afaics from 6.4.1.1).
> 
> Sure, but there's no need to blow away ACEs for named users and
> groups--anyone that cares about posix should be restricting them to
> grant no more than the mode group bits, but that's all.

The client still needs to know whether or not it should apply the umask.
I therefore don't see how changing server behaviour to the above can
solve the problem in practice.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFS4 ACL <-> Posix ACL

[J. Bruce Fields]

On Tue, Mar 24, 2009 at 07:20:52PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 19:02 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 06:54:41PM -0400, Trond Myklebust wrote:
> > > On Tue, 2009-03-24 at 18:34 -0400, J. Bruce Fields wrote:
> > > > On Tue, Mar 24, 2009 at 06:22:47PM -0400, Trond Myklebust wrote:
> > > > > On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> > > > > > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > > > > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > > > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > > > > > >> How do other people share public files with NFS4? If there is no other
> > > > > > > > > >> way than setting the users's umask to 002, this would practically
> > > > > > > > > >> limit the use of NFS4 to private shares like home directories.
> > > > > > > > > >
> > > > > > > > > > I don't understand why--can't you use the user-private-group trick?:
> > > > > > ...
> > > > > > > > > - we actually have directories where files should only be group readable.
> > > > > > > > 
> > > > > > > > I don't get it--why not set an inheritable acl on those directories that
> > > > > > > > permits only read to the group?
> > > > > > > 
> > > > > > > That only works if the client actually respects the acl...
> > > > > > 
> > > > > > I don't understand.  ACL enforcement and inheritance are both done on
> > > > > > the server side.
> > > > > > 
> > > > > > The problem is just that the umask is applied on the client side.  But
> > > > > > if the umask is 002, and an inheritable ACL permits only read, then the
> > > > > > result of inheritance and umask-application will be an ACL that permits
> > > > > > reads (and only reads) to the group owner (and to any named users and
> > > > > > groups).
> > > > > 
> > > > > The client currently always sends a mode. My interpretation of RFC3530
> > > > > is that this will always override the inherited ACL (see the discussion
> > > > > in OP_OPEN and OP_CREATE w.r.t. the createattrs field).
> > > > 
> > > > Depends on what you mean by "override".  It shouldn't be replacing the
> > > > inherited ACL wholesale; see 6.4.3.
> > > 
> > > That is the v4.1 draft, which is hardly normative for NFSv4.0 servers.
> > > Note, however, that in the v4.1 case too, the server is required to
> > > replace the OWNER@, GROUP@ and EVERYONE@ fields when the client sends a
> > > mode attribute (afaics from 6.4.1.1).
> > 
> > Sure, but there's no need to blow away ACEs for named users and
> > groups--anyone that cares about posix should be restricting them to
> > grant no more than the mode group bits, but that's all.
> 
> The client still needs to know whether or not it should apply the umask.
> I therefore don't see how changing server behaviour to the above can
> solve the problem in practice.

Yeah, throwing out the umaskless-mode doesn't help unless it we also
have something like the mode_set_masked.

--b.