Subject: [nfsv4] Clarification on ID mapping with NFSv4/4.1

From: Ajith K <[email-masked]>
Date: Fri, 15 Jul 2011 10:23:00 +0530

Hello,

The RFC 3530 & 5661 both describe uid/gid mapping to be performed by NFS
v4/4.1 server.
I'm a bit confused on how to achieve this and would like to understand which
uid/gid an NFSv4/4.1
server SHOULD use to authenticate & authorize a remote user operation.

1. SHOULD we use The RPC credentials (uid/gid)  from RPC header,
which we get from AUTH_SYS / AUTH_DH / RPCSEC_GSS to perform remote NFS file
operations ?

2. SHOULD the NFS v4/4.1 server ALWAYS use mapped local uid/gid to
authenticate/authorize  the remote user ?
If we do so, Can this not lead to hole where you can forge an "owner@domain"
and get an access to a File ?

I also read that the "owner@domain" / "owner_group@domain" fields are
RECOMMENDED attributes for a file object.
These are sent during CREATE/SETATTR/GETATTR operations to convert to local
UID/GID.
I understand this would be useful for a client on different ID spaces to
create a file.

But, the file ACCESS arguments does not describe "owner@domain" /
"owner_group@domain" fields.
How could a client on different ID space access this file later which it
creates ?

struct ACCESS4args {
/* CURRENT_FH: object */
uint32_t access;
}

18.1.4. IMPLEMENTATION
In general, it is not sufficient for the client to attempt to deduce
access permissions by inspecting the uid, gid, and mode fields in the
file attributes or by attempting to interpret the contents of the ACL
attribute.* This is because the server may perform uid or gid mapping
or enforce additional access-control restrictions. It is also
possible that the server may not be in the same ID space as the
client.* In these cases (and perhaps others), the client cannot
reliably perform an access check with only current file attributes.

-- 
Ajith K
------------------------------------------
Almost anything you do will be insignificant,
but it is very important that you do it -- Gandhi
------------------------------------------

---

From: Rick Macklem <[email-masked]>
Date: Fri, 15 Jul 2011 10:44:12 -0400 (EDT)

Ajith K wrote:
> Hello,
> 
> The RFC 3530 & 5661 both describe uid/gid mapping to be performed by
> NFS v4/4.1 server.

I believe that the mapping you refer to is what is used within the NFSv4
RPCs. That is, the mapping of the Owner and OwnerGroup attributes.

> I'm a bit confused on how to achieve this and would like to understand
> which uid/gid an NFSv4/4.1
> which we get from AUTH_SYS / AUTH_DH / RPCSEC_GSS to perform remote
> NFS file operations ?
> 
A server will normally use the credentials in the RPC header in order to
authenticate a "user" and then decide if that "user" is authorized to perform
the operation. I put "user" in quotes because it is normally a uid + gid list
for a POSIX-like server, but might be something else for a different server
implementation.

For example, a POSIX-like server will need to decide how to translate a
GSSAPI principal name to a uid + gid list and that is server implementation
specific. (A typical POSIX-like server might call getpwname(user-principal)
to get the uid and first gid, then look at the group database for additional
gids.)

> If we do so, Can this not lead to hole where you can forge an
> "owner@domain" and get an access to a File ?
> 
> These are sent during CREATE/SETATTR/GETATTR operations to convert to
> local UID/GID.
> I understand this would be useful for a client on different ID spaces
> to create a file.
> 
For RFC3530, the "name@domain" was the required way for the Owner and
OwnerGroup attributes to be sent on the wire (has no direct relation
with authentication in the RPC header, although obviously the same "name"
may refer to a "user" for both). As I understand it, RFC3530bis relaxes
this, so that "502" can be used as a valid Owner/OwnerGroup attribute string.
(My understanding is that this was done so that an NFS root file system can
 be made to work for diskless clients. ie. The root fs works before any
 mapping service is available.)

> How could a client on different ID space access this file later which
> it creates ?
> 
I'll let the guy who has been working on the issue of dealing with
multiple naming domains try and answer this. (The short version is that
handling multiple naming domains is still an open problem.)

> attribute. This is because the server may perform uid or gid mapping
> client. In these cases (and perhaps others), the client cannot
The server will use the authenticator in the RPC header + stored
attributes for the file to generate the reply to Access. There is no
guarantee that this Access reply will remain valid/accurate for any
amount of time after the reply, in general. However, I believe a client
can assume that the replied access information will continue to be
correct for the "user" represented by the authenticator in the RPC
header, so long as the client holds a delegation for that file.
(No delegation--> hope it's correct for a little while, just like
 NFSv3 and let the sysadmin control how long a cached attribute is
 believed to be correct via a mount option or similar.)

Hopefully others will jump in with clarifications, if I got things
wrong, rick
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Ajith K <[email-masked]>
Date: Mon, 18 Jul 2011 10:29:22 +0530

Hi Ric,

Thanks for the pointers. The read trough the RFC3530bis, I understand it
better now.

-Ajith