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

From: "Mike Eisler" <[email-masked]>
Date: Mon, 7 Apr 2008 15:00:21 -0700 (PDT)

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.

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

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 07 Apr 2008 18:50:09 -0400

> the file. The rationale is in the proposed changes.

While the rules seem sane enough for POSIX clients and server, I'm still
a tad confused. Don't these rules mean that Windows servers may never
set ACCESS4_EXECUTE because NTFS doesn't support execute mode bits?

If so, won't that cause an interoperability issue?

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 7 Apr 2008 19:04:36 -0400

> 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.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 7 Apr 2008 16:20:08 -0700 (PDT)

> If so, won't that cause an interoperability issue?

After doing chmod a-x Makefile from cygwin,
the Windows XP properties window shows

Permissions for Eisler, Michael
                      Allow Deny
Full Control
Modify
Read & Execute
Read                    x
Write
Special Permissions     x

--------------

So I think we are fine. If anything NTFS is more NFS ready in
this regard than POSIX file systems, because it makes the sane
observation that if one has execute rights, one has read rights,
unlike POSIX.

But let's say a file system doesn't have execute permission bits.

If the file has a .exe extension (or other executable
extension) the server probably returns
ACCESSx_EXECUTE. So with a mild change in the proposed text,
Windows client to Windows server interoperability is not an issue.

Windows client to POSIX server interoperability isn't an issue either.

So it is POSIX client to Windows server interoperability that would
potentially be an issue.

If there are no execute bits, then pre-NFSv4.1, what does
an NFS server return when it receives an ACCESS request
with ACCESSx_EXECUTE in the access field for a file stored on
a file system? The proposal is for the server to clear
ACCESSx_EXECUTE from the supported field of the result which
was the implied behavior for NFSv4.0 too. The proposal
states that ACCESS4_EXECUTE is not set in the supported
field of the reply, then the client has to send ACCESS with
ACCESS4_READ, and live with issues the preamble to the rules
discusses.

If this causes problems for pre-NTFS Windows filesystems, like
FAT then I can live with it.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 7 Apr 2008 16:42:49 -0700 (PDT)

> Have any users actually stumbled across that kind of problem before?)

I have war stories. The ONTAP NFSv[34] server has always returned
ACCESSx_EXECUTE when uid zero was mapped to zero (i.e. unchanged).
This caused a spectacular problem with an NFS client once.

> Sure is a lot of text, though.

I'm open to suggestions to make it more concise. This is my 4th
major iteration and the 1st was like War & Peace (an apt
metaphor this type of interop issue).

> Do we really need to say this here?

I believe so, because the point is that even though execute bits
allow READ and OPEN for read to succeed, ACCESS (ACCESS4_READ)
is not the way to find that out; ACCESS (ACCESS4_EXECUTE) is the
one true way.

> Does this need to be said here?

If you don't have said, then we are open to misinterpretations. E.g.

$ ls -l a.out
ls -l a.out
---x--x--x 1 mre mkgroup-l-d 16642 Mar 31 21:59 a.out

Now, we want

    test -x a.out

to succeed, and

    test -r a.out

to fail, correct?

With the proposed text, we allow programs like 'test' to rely completely
on access()/NFSv4.1 ACCESS to do the right thing, without having
to inspect permission bits.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 07 Apr 2008 20:00:04 -0400

> to inspect permission bits.

BTW: is anyone capturing this for the (hopefully forthcoming)
clarification/bugfix of the v4.0 spec? AFAIK, this is an issue with
ramifications that go all the way back to NFSv2...

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 8 Apr 2008 12:55:44 -0700 (PDT)

>> If you don't have [it] said, then we are open to misinterpretations. E.g.
[...]
> ramifications that go all the way back to NFSv2...

NFSv3, v2 had no ACCESS.

Regardless my focus is on NFSv4.1 and beyond. Cleaning up the v4.0 is
nice to have, but evne so some cleanups that introduce interop problems are
likely best left alone. And, assuming my proposal is deemed acceptable for
v4.1, ACCESS is a cleanup that should not be incorporated in v4.0.

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 8 Apr 2008 15:59:47 -0400

I recall that we had a keyword in the nfsv4-editor.com issue tracker for
items that seemed as if they would apply to an RFC3530 update.  We
probably didn't use it consistently but if this will be attempted, there
is at least the start of the list  of things to deal with.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2008 3:56 PM
To: [email-masked]
Subject: Re: [nfsv4] proposed slight change to ACCESS and wordsmithing
changes for chapter 18 (thru the LINK operation)

[...]

NFSv3, v2 had no ACCESS.

Regardless my focus is on NFSv4.1 and beyond. Cleaning up the v4.0 is
nice to have, but evne so some cleanups that introduce interop problems
are
likely best left alone. And, assuming my proposal is deemed acceptable
for
v4.1, ACCESS is a cleanup that should not be incorporated in v4.0.

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 8 Apr 2008 20:28:17 -0700 (PDT)

I've corrections for the typos Bruce pointed out, and
tweaked the text to allow for servers that indicate
executability through other means (e.g.
file name suffixes).

http://eisler.com/nfsv4-wg/2008-04-08-retention.html

As you might guess from the name of the web page,
the retention changes David Black outlined are
also in that page.

Sorry to those tracking both issues for the duplicate
message.