[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    Re: [nfsv4] user/group IDs remapping
From:       David Robinson <David.Robinson () sun ! com>
Date:       2005-11-16 22:08:02
Message-ID: 60f63b948440c48284bfbf986354d8d5 () sun ! com
[Download RAW message or body]

I don't know what all implementations do, for any specific
implementation details you need to seek out the vendor
or community that supports it.

On Nov 16, 2005, at 1:49 PM, Igor Shmukler wrote:
> I am trying to determine whether NFSv4 would allow creating exports
> that would not remap user and group ids, but instead keep them as they
> are.

I think what you are asking is if they can use numeric
owner and owner_groups instead of symbolic user@domain?

> User igor has some user id and group id on client machine, but server
> has no idea about this. I want server to just keep numeric value.
>
> I am not sure whether this would be possible since, I have no clue how
> server would know whether another user say Bruce has right to
> read/write in my directory, if he belongs to several groups and
> default group is different.
>
> Are rules enforced locally or on NFS server?
>
> Does my question even make sense?
>
> It appears that -maproot=root might even do the trick, but would it?

First, the NFSv4 standard has a strong SHOULD that owner and owner_group
are of the form "name@dns.domain". While using a numeric string is
not strictly a protocol error it is strongly frowned upon.

There are also two different issues between what is used to determine
permissions versus what is used for display or returned in an
API like lstat().

The client should not use the owner and owner_group that is returned
in the GETATTR to determine if a user has permissions to perform
and operation or not.  Access control can only be performed by
the server based on the security credentials in the RPC header
and the ACLs that are stored on the server. At best what the
client sees is a hint, but cannot be relied upon. The simpliest
example is that a server may have a more complex access control
model than can be represented in the protocol so the maps it
to a 'safe' subset. But the client cannot know this and must
consult the server via ACCESS, OPEN, or simply trying the operation.

What is displayed is also an issue. On a system like Solaris a
name@domain that cannot be translated into a local uid/gid
is displayed as user 'nobody'. Even if the uid/gid was sent
numerically there is only a small advantage of displaying
it as 12345 versus nobody, in both cases the actual owner is
not known because there lacks an identity on the system. But
because this should not affect access checking it has only
a minor impact.

As an example, a full build of the Solaris source over NFSv4
with mismatched domains, all files appear to be 'nobody', will
produce a runable OS image as long as the user has permissions
to read/write on the server.

There has been discussions about producing a common approach to
mapping owners between differing domains, but no significant
progress has been made.

As one implementation detail about Solaris, in order to boot
a diskless system it needs to solve the ckicken and egg
problem of how to load the OS image and utilities in order
to start the nfsmapid translation daemon. To solve this
problem Solaris will run with only numeric strings as the
owner/owner_group until the system has gotten far enough along
to start the nfsmapid daemon. Once it is started it will
never again use numeric strings (killing nfsmapid will not
make it revert back to numeric strings, but will just cause
everything to be nobody).

	-David


_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
[prev in list] [next in list] [prev in thread] [next in thread]