From mboxrd@z Thu Jan 1 00:00:00 1970 From: Spencer Shepler Subject: Re: filesystem client mapping of uid_t/gid_t field in lookup Date: Mon, 16 May 2005 14:03:08 -0500 Message-ID: <20050516190308.GD10360@sheplap.Central.Sun.COM> References: <1116052679.13863.38.camel@lade.trondhjem.org> Reply-To: spencer.shepler@sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Trond Myklebust , linux-fsdevel@vger.kernel.org, Steve French Return-path: Received: from brmea-mail-3.Sun.COM ([192.18.98.34]:23937 "EHLO brmea-mail-3.sun.com") by vger.kernel.org with ESMTP id S261812AbVEPTDM (ORCPT ); Mon, 16 May 2005 15:03:12 -0400 To: Bryan Henderson Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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