Subject: [nfsv4] NFS & processes that call seteuid()

From: Rayson Ho <[email-masked]>
Date: Tue, 3 Mar 2009 17:56:38 -0500

I am wondering if it is correct for an application to open a file as a
normal user (mainly to workaround root squash), calls seteuid() to set
euid back to root, and then does some NFS I/O as root??

On Unix, as long as the process has a valid file descriptor, it can
then seteuid() back to root and perform I/O. Is it the same case for
NFS filehandles?

I read the NFS Illustrated book and also googled a bit, but I could
not find out whether it is correct or not...

Rayson

---

From: Rick Macklem <[email-masked]>
Date: Wed, 4 Mar 2009 10:32:12 -0500 (EST)

> then seteuid() back to root and perform I/O. Is it the same case for
The short answer is no. Normally NFS servers check access permissions for
all read/write ops, based upon the credentials provided to that RPC. One
common exception is allowing the file's owner to read/write even if the
mode bits don't allow it. Although NFSv4 has an OpenStateid that can be
sent in the read/write request (it can also be a stateid for a delegation
or byte range lock), it is used to refer to current lock state for the
file and is not considers a passkey to allow I/O.

Since the above tends to be underspecified in the RFCs, each server
implementation may vary on this, but in general, NFS servers aren't and
cannot provide POSIX compliant behaviour.

rick

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 4 Mar 2009 08:18:26 -0800 (PST)

> then seteuid() back to root and perform I/O. Is it the same case for

You could do that but it should be pointless.

Most (IMHO, correct) NFS clients will send the
RPCs with credentials of the user that opened the file, not the
effective uid of the process. This allows setuid and setgid processes
that inhereit open file descriptors to work correctly.

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

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Rick Macklem <[email-masked]>
Date: Wed, 4 Mar 2009 12:30:14 -0500 (EST)

> that inhereit open file descriptors to work correctly.
Oops, yes, I had forgotten about that, I was just thinking from the
server's perspective.

Thanks for pointing that out Mike, rick

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Mar 2009 11:47:11 -0600

> Oops, yes, I had forgotten about that, I was just thinking from the

The server has no idea if the client presents POSIX or POSIX-like APIs
to applications.  The protocol is designed so that clients that do
provide POSIX or POSIX-like APIs can implement POSIX semantics, but it's
up to the client to do that.

If the question is which RPC credentials are used when executing the
following open()s in a POSIX-compliant client and what RPC credentials
are used when executing the following read()s:

	assert(getuid() == 0 && geteuid() == 0);
	fd1 = open(somepath1, O_RDONLY);

	assert(fd1 >= 0);
	assert(someuser1 != 0 && someuser2 != 0 && someuser1 != someuser2);
	assert(seteuid(someuser1) == 0);
	fd2 = open(somepath2, O_RDONLY);

	assert(seteuid(0) == 0);
	assert(setreuid(someuser1, -1) == 0);
	assert(seteuid(someuser1) == 0);
	fd3 = open(somepath3, O_RDONLY);

	assert(setuid(0) == 0);
	assert(setuid(someuser2) == 0);
	/* now read from fd1, fd2 and fd3 */

Then the answer is that fd1 is opened and read with the RPC credentials
that correspond to UID 0, and fd2 and fd3 are opened and read with the
credentials that correspond to <someuser>.

Nico
--

---

From: Rick Macklem <[email-masked]>
Date: Wed, 4 Mar 2009 14:40:08 -0500 (EST)

> credentials that correspond to <someuser>.

I know it's picking nits, but an NFS client can only achieve "approximate
POSIX semantics" (see exclusive open or the case where there is a
chown/chmod/setfacl on the file that makes access fail for the opener 
while the file is open or...), so I think saying "POSIX compliant" is too 
strong a term (POSIX like sounds about right to me).

Nico, I'm sure you are aware of this, but I thought I'd nitpick for other
readers who might not be, rick

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Mar 2009 13:58:26 -0600

> strong a term (POSIX like sounds about right to me).

Changing a file's permissions should not invalidate open file
references.  My understanding is that for NFSv4 that is indeed the case,
though it's the client's job to use the RPC credentials used at open
time.  I also thought the exclusive open case was supported in NFSv4.

> readers who might not be, rick

O_APPEND is particularly hard to do with POSIX semantics with NFS (any
version).  With v4 if the client has a delegation then O_APPEND is a
local problem, else the clients have to lock from [at least] EOF [if not
offset 0] to the max offset around each append write.  I suspect most
clients don't, but I don't recall what the Solaris client does.

Nico
--