Subject: [nfsv4] NFSv4 ACLs: ACE4_WRITE_ATTRIBUTES clarification

From: Lisa Week <[email-masked]>
Date: Wed, 15 Dec 2004 11:09:11 -0700

Hi all,

There has been a side band conversation going on about the meaning of 
the ACE4_WRITE_ATTRIBUTES access mask bit.

Just in case you are interested, here is a summary of what has been said:

* Hummingbird takes ACE4_WRITE_ATTRIBUTES to include (quoted from email):

[Outside of FILE_ATTRIBUTE_HIDDEN] it also includes 
FILE_ATTRIBUTE_ARCHIVE, FILE_ATTRIBUTE_SYSTEM as well as
file times (create, access, modify). The FILE_ATTRIBUTE_xxx access mask bits
are the only other relevent NTFS attributes that can be mapped directly onto
NFSv4.

It does not include setting the end-of-file marker past EOF to extend the
file.

(Quoted from a separate email):
It seems odd to me, but NTFS will allow the WRITE_ATTRIBUTES access mask set
without the ability to modify the file.  As an example, as a user with this
ability, I can mark a file as hidden without actually being able to modify
the contents of the file.

I am not sure how that would be used in the real world, but it is supported.

* NetApp takes ACE4_WRITE_ATTRIBUTES to include (quoted from email):

For acl or mode we look at WRITE_ACL, for owner and group we look at
WRITE_OWNER, for size we look at WRITE perms. For changes to times we
look at WRITE_ATTRIBUTES.

To clarify:
[If a user (who is not the OWNER of the file) is allowed 
ACE4_WRITE_DATA, but denied ACE4_WRITE_ATTRIBUTES] the modify time will 
get updated because of the write. If they come in and try to change the 
modify time themselves, that request will be denied.

[If a user (who is not the OWNER of the file) is allowed 
ACE4_WRITE_ATTRIBUTES] they can set it to the server time or a valid 
time supplied by the client.

* Linux is taking it to mean the ability to set the times to an 
arbitrary time.

(Quoted from email):

There's a difference between the automatic updates to the current time
that happen when you do a read or write, and an explicit modification of
the time to an arbitrary value.  From posix's description of utime:

	"The utime() function shall set the access and modification
	times of the file named by the path argument.

	"If times is a null pointer, the access and modification times
	of  the file  shall  be  set  to the current time. The effective
	user ID of the process shall match the owner of the file, or
	the  process  has  write permission to the file or has
	appropriate privileges, to use utime() in this manner.

	"If times is not a null pointer, times shall be interpreted as a
	pointer to  a  utimbuf structure and the access and modification
	times shall be set to the values contained in the designated
	structure.  Only a process with the effective user ID equal to
	the user ID of the file or a pro- cess with appropriate
	privileges may use utime() this way."

To summarize: you get the ability to set the time to the current time if
you have write permission (it's like a zero-length write), but you only
get the ability to set it to an arbitrary value if you're the owner.

It would make sense to me to maintain the same distinction in v4, and
take WRITE_ATTRIBUTES to determine only the right to set an *arbitrary*
time.  The ability to set to current time should be granted to anyone
with write permission even without an explicit WRITE_ATTRIBUTES
permission, since writes always set mtime to the current time anyway.

* Solaris is the same as Linux and it's behavior will continue to be 
consistent with the I-D.

Thanks,
Lisa Week
Sam Falkner

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 15 Dec 2004 14:43:34 -0500

So I think that the current proposal for how to use the 14 bits in v4
ace bitmasks when mapping between v4 and posix acls is this:

	Everyone is given READ_ATTRIBUTES | READ_ACL | SYNCHRONIZE.
	The owner is given WRITE_ATTRIBUTES | WRITE_ACL.

	Other bits depend on mode bits:

	r-> READ_DATA | READ_NAMED_ATTRS
	w-> WRITE_DATA | WRITE_NAMED_ATTRS | APPEND_DATA | DELETE_CHILD
	x-> EXECUTE

	DENY aces are given a bit mask that is the complement of
	the bit mask determined as above, except that we never set any
	bits not named in the protocol, and we never set the DELETE
	or WRITE_OWNER bits.

Have I gotten anything wrong in the description above?

The Linux implementation doesn't do WRITE_OWNER as above, so I intend to fix
that.  There's some disagreement over the {READ,WRITE}_ATTRIBUTES bits as no
one knows what they're for.  Also, I would rather treat SYNCHRONIZE like DELETE
and WRITE_OWNER, but the choice is somewhat arbitrary and allowing SYNCHRONIZE
is what everyone else is doing at this point and what Windows clients seem to
prefer as the default.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 15 Dec 2004 15:43:18 -0500

> ace bitmasks when mapping between v4 and posix acls is this:

I've also been trying to think about how to make nfsv4->posix mapping
more forgiving, and how to simplify acl management in the case where
both posix and nfsv4 user acl utilities are available.

Currently if I touch a file and ask for its nfsv4 acl this is what I
get:

$ touch /mnt/puzzle/test1/FOO
$ nfs4_getfacl /mnt/puzzle/test1/FOO 
1: A::OWNER@:rwanNtTcCy
2: D::OWNER@:x
3: A:g:GROUP@:rntcy
4: D:g:GROUP@:waNxTC
5: A::EVERYONE@:rntcy
6: D::EVERYONE@:waNxTC

All that just to say the equivalent of "rw-r--r--".  Ugh!

It's hard to interpret, and harder still to modify, especially if the
server will reject anything that doesn't have every single bit set
correctly.

We could make the server mapping more forgiving by performing a
few transformations on the input nfsv4 acl before mapping it to a posix
acl:
	1. If the DENY aces created by the posix->nfsv4 mapping are
	   left out, recreate them as necessary.  (We're erring on the
	   side of denying permissions, which is safe.)
	2. If the input nfsv4 acl fails to either allow or deny some
	   bit, then permit ourselves to allow or deny those bits as
	   necessary to make the mapping work.  (Behaviour is undefined
	   when we neither allow nor deny, so we're free to do what we
	   want.)

A server that did both of these would be able to handle an acl as simple
as:

A::OWNER@:rw
A::GROUP@:r
A::EVERYONE@:r

instead of requiring an acl like the above.

Clients doing posix mapping could similarly accept such simplified acls
from servers[1].  Which might make it reasonable for servers to actually
return such acls.  That would mean users wouldn't have to see the full
6-ace acl above, when the server was really only dealing with posix
acls.

A server that actually did deal with full nfsv4 acls couldn't return the
simplified versions.  But in that case all those extra bits would *mean*
something, and could be independently modified by the user.

Comments?

--b.

Footnote:
[1] Actually, not quite: it shouldn't perform step #1 in all cases, as
it may lead to misrepresenting an acl as more secure than it really is.
So deny aces would still be necessary, e.g., in the case of r--rw-rw-,
since

A::OWNER@:r
A::GROUP@:rw
A::EVERYONE@:rw

is more permissive than the corresponding posix acl, since it doesn't
deny write to the owner.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 15 Dec 2004 16:21:34 -0500

> A server that did both of these would be able to handle an acl as simple

and hopefully even further simplified to:

A::OWNER@:rw
A::EVERYONE@:r

since the group and everyone bits were identical.