filesystem client mapping of uid_t/gid_t field in lookup

filesystem client mapping of uid_t/gid_t field in lookup

[Steve French]

RFC 1813 states:
   Using user
   ids and group ids implies that the client and server either
   share the same ID list or do local user and group ID mapping.
   Servers and clients must agree on the mapping from user to uid
   and from group to gid, for those sites that do not implement a
   consistent user ID and group ID space. In practice, such mapping
   is typically performed on the server, following a static mapping
   scheme or a mapping established by the user from a client at
   mount time.

which implies that other network filesystem clients passed in a table of 
uid mappings
at mount time. This would be extremely useful, but seems unwieldy to pass
in via mount.  Without adding an ioctl to set the uids for a particular 
mount (actually in my case it would
probably be for all mounts on the client to the same sharename (export) 
and/or a particular
server), would this be better to pass in via proc (which also seems 
awkward due
to size of proc writes presumably getting bigger than 4K if there were a 
lot of mappings).

Re: filesystem client mapping of uid_t/gid_t field in lookup

[Trond Myklebust]

fr den 13.05.2005 Klokka 17:50 (-0500) skreiv Steve French:
> RFC 1813 states:
>    Using user
>    ids and group ids implies that the client and server either
>    share the same ID list or do local user and group ID mapping.
>    Servers and clients must agree on the mapping from user to uid
>    and from group to gid, for those sites that do not implement a
>    consistent user ID and group ID space. In practice, such mapping
>    is typically performed on the server, following a static mapping
>    scheme or a mapping established by the user from a client at
>    mount time.
> 
> which implies that other network filesystem clients passed in a table of 
> uid mappings at mount time.

Woah...All it says is that the NFSv3 client and server must have
matching uid/gid mappings. It says nothing about implementation details.
Doing that sort of thing by trying to define static mappings at mount
time is an implementation that will never scale.

In NFSv4 (which is the only NFS implementation that supports native
uid/gid mapping since it defines a globally unique username/groupname
space for use on the wire) the uid/gid mapping is done using upcalls to
a userland daemon on both the client and server side. A cache is used in
order to avoid too many upcalls. Why would this sort of approach be
impractical for CIFS?

Cheers,
  Trond

Re: filesystem client mapping of uid_t/gid_t field in lookup

[Jamie Lokier]

Trond Myklebust wrote:
> In NFSv4 (which is the only NFS implementation that supports native
> uid/gid mapping since it defines a globally unique username/groupname
> space for use on the wire) the uid/gid mapping is done using upcalls to
> a userland daemon on both the client and server side. A cache is used in
> order to avoid too many upcalls. Why would this sort of approach be
> impractical for CIFS?

It would be even nicer if they could share the same mapping daemon.

-- Jamie

Re: filesystem client mapping of uid_t/gid_t field in lookup

[Steve French]

Trond Myklebust wrote:

>the uid/gid mapping is done using upcalls to
>a userland daemon on both the client and server side. A cache is used in
>order to avoid too many upcalls. Why would this sort of approach be
>impractical for CIFS?
>
>Cheers,
>  Trond
>
>  
>
It could be done with upcalls which populate a cache of uid mappings, 
but I was worried about avoiding all deadlock cases - not just the 
problem of making sure the user space daemon never dies, and the 
performance implications, but what worried me more was having to do a 
task switch in lookup (and readdir etc.)  to an upcall thread to resolve 
some mappings might result in deadlock if the upcall thread could ever 
get blocked on writeback of inode data that the kernel code has to page 
out.  This also means that the upcall thread has to be aware of which 
smb_uid (smb session) and/or which tree connection (mount to the same 
target UNC name) the mapping is for which is possible but perhaps harder 
to implement than the approach that RFC1813 mentions ie "mapping 
established by the user from a client at mount time."

Re: filesystem client mapping of uid_t/gid_t field in lookup

[Bryan Henderson]

>> RFC 1813 states:
>>    Using user
>>    ids and group ids implies that the client and server either
>>    share the same ID list or do local user and group ID mapping.
>>    Servers and clients must agree on the mapping from user to uid
>>    and from group to gid, for those sites that do not implement a
>>    consistent user ID and group ID space. In practice, such mapping
>>    is typically performed on the server, following a static mapping
>>    scheme or a mapping established by the user from a client at
>>    mount time.
>> 
>> which implies that other network filesystem clients passed in a table 
of 
>> uid mappings at mount time.
>
>Woah...All it says is that the NFSv3 client and server must have
>matching uid/gid mappings. It says nothing about implementation details.

Then what do you make of the sentence that starts, "In practice, such 
mapping is typically performed..."?  That's nothing if not a statement 
about implementation details.  And I agree that this sentence implies what 
Steve says.

It's somewhat of a surprise, however, because I always thought the mapping 
was _typically_ done, if at all, by a table installed on the server 
without client involvement.  A table that says, "whenever client A mounts, 
consider his uid 8 to be our uid 13."  I base this on a vague memory, 
though.  Correct me if I'm wrong.

The only uid-mapping NFS server I've ever used myself does neither.  The 
client establishes the mapping via a login protocol which is independent 
of mount.  Come to think of it, the login protocol
in this system doesn't have to be initiated by the client.  A third party 
can tell the server, "consider uid 8 from Client A to be uid 13."

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

Re: filesystem client mapping of uid_t/gid_t field in lookup

[Spencer Shepler]

On Mon, Bryan Henderson wrote:
> >> RFC 1813 states:
> >>    Using user
> >>    ids and group ids implies that the client and server either
> >>    share the same ID list or do local user and group ID mapping.
> >>    Servers and clients must agree on the mapping from user to uid
> >>    and from group to gid, for those sites that do not implement a
> >>    consistent user ID and group ID space. In practice, such mapping
> >>    is typically performed on the server, following a static mapping
> >>    scheme or a mapping established by the user from a client at
> >>    mount time.
> >> 
> >> which implies that other network filesystem clients passed in a table 
> of 
> >> uid mappings at mount time.
> >
> >Woah...All it says is that the NFSv3 client and server must have
> >matching uid/gid mappings. It says nothing about implementation details.
> 
> Then what do you make of the sentence that starts, "In practice, such 
> mapping is typically performed..."?  That's nothing if not a statement 
> about implementation details.  And I agree that this sentence implies what 
> Steve says.
> 
> It's somewhat of a surprise, however, because I always thought the mapping 
> was _typically_ done, if at all, by a table installed on the server 
> without client involvement.  A table that says, "whenever client A mounts, 
> consider his uid 8 to be our uid 13."  I base this on a vague memory, 
> though.  Correct me if I'm wrong.
> 
> The only uid-mapping NFS server I've ever used myself does neither.  The 
> client establishes the mapping via a login protocol which is independent 
> of mount.  Come to think of it, the login protocol
> in this system doesn't have to be initiated by the client.  A third party 
> can tell the server, "consider uid 8 from Client A to be uid 13."

At the time that RFC was crafted, the login protocol most commonly
used was the PCNFS protocol that most DOS/Windows NFS implementations 
to map the username to a uid to be used over the wire.  All of that 
mapping was done at user level at the server.

The rest of the mapping reference is the classic uid/gid mapping done
via /etc/passwd or NIS, etc.

That was the intent at least.

Spencer

Re: filesystem client mapping of uid_t/gid_t field in lookup

[Trond Myklebust]

må den 16.05.2005 Klokka 11:18 (-0700) skreiv Bryan Henderson:
> >> RFC 1813 states:
> >>    Using user
> >>    ids and group ids implies that the client and server either
> >>    share the same ID list or do local user and group ID mapping.
> >>    Servers and clients must agree on the mapping from user to uid
> >>    and from group to gid, for those sites that do not implement a
> >>    consistent user ID and group ID space. In practice, such mapping
> >>    is typically performed on the server, following a static mapping
> >>    scheme or a mapping established by the user from a client at
> >>    mount time.
> >> 
> >> which implies that other network filesystem clients passed in a table 
> of 
> >> uid mappings at mount time.
> >
> >Woah...All it says is that the NFSv3 client and server must have
> >matching uid/gid mappings. It says nothing about implementation details.
> 
> Then what do you make of the sentence that starts, "In practice, such 
> mapping is typically performed..."?  That's nothing if not a statement 
> about implementation details.  And I agree that this sentence implies what 
> Steve says.

I read Steve's proposal as involving pushing static uid/gid mappings
down into the kernel on the client at mount time. I don't read the RFC
as implying that as being a scheme that is mandatory to implement. In
fact I can think of very few clients that do so.

The cases of client-side mapping that leap to mind are the old PCNFS
clients that Spencer mentioned, and stuff like the old VMS
implementations. In both those cases the real problem was that the
clients needed to map their local non-uid/gid based naming schemes into
an AUTH_SYS credential. That is basically the same mapping that we
expect to be performed on login using /etc/passwd, /etc/group and
friends on Linux.

> It's somewhat of a surprise, however, because I always thought the mapping 
> was _typically_ done, if at all, by a table installed on the server 
> without client involvement.  A table that says, "whenever client A mounts, 
> consider his uid 8 to be our uid 13."  I base this on a vague memory, 
> though.  Correct me if I'm wrong.

That is far more typical. The server uses this information in order to
enforce security, so it makes sense for it to be involved in deciding
which remote uids/gids are trusted to be mapped into local uids/gids.

root_squash and all_squash are the only mappings currently supported by
Linux knfsd (at least in the case of AUTH_SYS) but other servers may
support more complex mappings.

> The only uid-mapping NFS server I've ever used myself does neither.  The 
> client establishes the mapping via a login protocol which is independent 
> of mount.  Come to think of it, the login protocol
> in this system doesn't have to be initiated by the client.  A third party 
> can tell the server, "consider uid 8 from Client A to be uid 13."

RPCSEC_GSS basically boils down to "consider this strongly authenticated
channel from Client A to be whatever uid the principal maps to on your
server", so we've already got some support for that sort of thing.

Cheers,
  Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html