SImple name-to-id mapping with idmapd not working?

[J. Bruce Fields]

On Fri, Feb 29, 2008 at 01:18:57AM +0100, Alessio Gaeta wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> J. Bruce Fields ha scritto:
> > If you're using auth_unix (as opposed to kerberos), then permissions are
> > determined by uid's, *not* by names.  So in the above, the client-side
> > user named "Valentina" is going to be given the access of the
> > server-side user named "Alberto".
> > 
> > So your choices are to synchronize id's (and names!) across the client
> > and server, or switch entirely to kerberos.
> > 
> > In more detail: users are identified at two different layers of the
> > protocol:
> > 
> > 	- At the lower (rpc) level, each rpc call includes a credential
> > 	  that identifies the user.  In the case of auth_unix, this
> > 	  "credntial" is just a uid and a list of gid's.  In the case of
> > 	  kerberos, it's a cryptographic signature that gets mapped to
> > 	  some kerberos principal.
> 
> I read something about that (RPC only carries UID/GID in headers), but
> my guess was that idmapd was precisely intended to workaround this
> "limit".

Nope.  You're not the first to make the same mistake, and the confusion
is a problem--I'm not quite sure what to do about it.  But idmapd only
handles the names that are used when setting and getting acls or file
owners.

...
> (Such schema, if valid, makes also me wonder why idmapd is needed on
> both server and client: everything could be done server-side

> I'm (clearly) not an NFS expert, but I feel that somehow odd: doesn't
> NFS already puts "names on wire", without idmapd?

Yes, NFSv4 does.

> The ACL stuff is
> already done by NFS itself, using attributes (OWNER and OWNER_GROUP),
> isn't it? idmapd should do what its name says: map names (provided by
> NFS) to *local* UID/GID (somehow overwriting those announced by the RPC
> call). If not is so, I'm wondering why one should use idmapd and how it
> could be useful.

We have no choice but to use idmapd for nfsv4, because the NFSv4
protocol uses names for acls and owners, whereas we need uid's to do
anything on either end.

In other words, idmapd isn't adding some special new feature--it's
needed for basic NFSv4 functionality.

If we also wanted to do id<->id mapping of auth_unix credentials, we'd
need a new mechanism for that.


> Am I saying nonsense?
> 
> Anyway, where could I find a comprehensive schema (such my hypothetical
> above) of client-server interaction with id mapping? I looked for it,
> but without luck, all refers to more complex scenarios...

I'm not sure.

--b.

> - --
> Alessio Gaeta
> http://meden.uni.cc
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHx09xirbk3DO+UZ0RAhr4AJ4u3hP0VXuhKvpFzuhyRhXxyJtnvACg1Cda
> Nx5ijptLZ1JJlEvCqg6WRGw=
> =GbTL
> -----END PGP SIGNATURE-----