Re: [nfsv4] proposed slight change to ACCESS and wordsmithing changes for chapter 18 (thru the LINK operation)

["J. Bruce Fields" <bfields at fieldses.org>]

On Mon, Apr 07, 2008 at 03:00:21PM -0700, Mike Eisler wrote:
> http://eisler.com/nfsv4-wg/2008-04-07-ch18_thru_link.html
> 
> The slight change to ACCESS is require that servers only
> look at the execute bits when determining if a user can execute
> the file. The rationale is in the proposed changes.

Seems sensible to me.  (And the path-searching example is interesting.
Have any users actually stumbled across that kind of problem before?)
Sure is a lot of text, though.

	"Note that the reply's supported and access fields MUST NOT
	contain more values than originally sent in the requests access
	field."

There's a missing apostrophe in "requests":

	"For example, if the client sends an ACCESS operation with only
	the ACCESS4_READ value set and the server supports this value,
	the server can set only ACCESS4_READ in the supported field even
	if it could have reliably checked other values."

"must not set more than" would be clearer than "can set only".

	"The reply's access field MUST NOT contain more values than in
	the supported field."

Drop the "in".

	"Requiring users and administers to set	read permissions on
	executable files in order to access them over NFS is not going
	to be acceptable some people."

"some people" should be "to some people".

	"Suppose the client's access() interface returns X_OK if the
	user is privileged, no execute permission bits are set on the
	regular	file's attribute, and the server's access() interface
	does not return X_OK in that situation."

The first comma should be an "and".  (The final "and the server's..." is
not a continuation of the same list of suppositions.)  The following
paragraph gets it right (though the first comma is unnecessary).  It
might also help clarify if the final "and" were made a "but", to
emphasize the contrast.

	"The client owns overall responsibility for determining execute
	access, and relies on the server to parse the execution
	permissions"

Should be "execute" permissions.

	"If the client is sending ACCESS in order to determine if the
	user can read the file, the client SHOULD set ACCESS4_READ in
	the request's access field."

Do we really need to say this here?

	"it SHOULD send an ACCESS request with both the ACCESS4_EXECUTE
	and ACCESS4_READ bits set the request's access field."

"set" should be "set in".

	"If the server supports execute permission bits, it MUST check
	just the execute permissions in the mode, acl, and dacl
	attributes when	it receives an ACCESS request with
	ACCESS4_EXECUTE set the access field."

"set" should be "set in".  Also, I think it would be simpler and more
accurate to say something like:

	"If the server supports execute permission bits, it MUST check
	only execute premissions, not read permissions, when determining
	whether the reply will have ACCESS4_EXECUTE set in the access
	field or not."

("More accurate" because I think it's possible for the server to have
some other security mechanism unknown to the protocol that could deny
execute permissions.)

	"If the server supports read permission bits, it MUST only check
	for read permissions in the mode, acl, and dacl attributes when
	it receives an ACCESS request with ACCESS4_READ set the access
	field. The server MUST NOT also examine execute permission bits
	when determining whether the reply will have ACCESS4_READ set in
	the access field or not."

Does this need to be said here?

--b.
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4