All of lore.kernel.org
 help / color / mirror / Atom feed
From: Spencer Shepler <spencer.shepler@sun.com>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	linux-fsdevel@vger.kernel.org,
	Steve French <smfrench@austin.rr.com>
Subject: Re: filesystem client mapping of uid_t/gid_t field in lookup
Date: Mon, 16 May 2005 14:03:08 -0500	[thread overview]
Message-ID: <20050516190308.GD10360@sheplap.Central.Sun.COM> (raw)
In-Reply-To: <OF3EBF6617.17C28313-ON88257003.0063694C-88257003.00649346@us.ibm.com>

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

  reply	other threads:[~2005-05-16 19:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 22:50 filesystem client mapping of uid_t/gid_t field in lookup Steve French
2005-05-14  6:37 ` Trond Myklebust
2005-05-14 11:38   ` Jamie Lokier
2005-05-15 22:37   ` Steve French
2005-05-16 18:18   ` Bryan Henderson
2005-05-16 19:03     ` Spencer Shepler [this message]
2005-05-16 22:23     ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050516190308.GD10360@sheplap.Central.Sun.COM \
    --to=spencer.shepler@sun.com \
    --cc=hbryan@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=smfrench@austin.rr.com \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.