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

[Alessio Gaeta]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry for the delay, but I've been busy and next Easter holidays have
done the rest.

>> I read the code, but it is undocumented,
> 
> Patches adding helpful comments are welcomed....

I would make them, but I need documentation to fully understand the
code... :)

> I think what you'd want to do is add a new server "cache" (see e.g.
> http://fieldses.org/~bfields/kernel/svc_caches/ for a rough description)
> which would map from a triple of (client name (as used in exports),
> "user"/"group", id number) to a local uid/gid.  You'd need to add
> corresponding code to rpc.mountd that listened for requests of that form
> and answered them.  And you'd need to figure out some syntax to allow
> the user to configure this (possibly in the /etc/exports file).

Thank you, interesting reading.
It is what I thought at first glance, an ID<->ID map (and relative
cache). But it is really needed to change caching code? As far I
understood, "real" file permission control is done using IDs in RPC
requests, as in structure svc_cred inside the svc_rqst (defined
respectively in include/linux/sunrpc/svc.h and
include/linux/sunrpc/svcauth.h). All work seems to be done in
nfsd_setuser(.) (linux/fs/nfsd/auth.c), where (AFAIU, ever) nfsd takes
the client's identity (with the *remote* IDs) to access files; here,
credentials are plainly taken from the svc_rqst. But what if one uses
instead nfs_map_name_to_uid(.) and nfs_map_name_to_gid(.) defined in
include/linux/nfs_idmap.h? It seems to me that ID mapping would be
straightforward... Of course, one should have username available in
auth.c (can one somehow use svc_request? I couldn't see how...).
Consider mine is a little more than an intuition; is it too simple to be
true?

> Though if you actually want this to work for something like a laptop,
> which might move around, you may want to do the mapping on the client
> side instead (since the only way the server has to decide which client's
> mapping to use is the ip address).  I don't know how you'd do
> that--maybe use the keyring code somehow to manage auth_unix
> credentials??

I didn't was thinking in such terms: the basic auth_unix is host based
and should stay so. Setting a static ip for a client (or configuring
DHCP server to assign a specific ip address per host) is a matter of
seconds; change an UID and all file permission is not so immediate.

> Though personally I think the effort would be much better spent on
> making kerberos as really easy to set up; there is, as you say, a
> perception that:
> 
>> deploying a NIS/Kerberos/LDAP service is clearly overscaled...
> 
> We should make it easy to set up Kerberos.  I don't know of any
> fundamental reason it has to be hard.  That would mean working with
> distributions to automate the setup, maybe providing some higher-level
> tools to manage users--I don't know.

I agree with you, security is important in any scenario, as "lifestyle",
and distributions should take care of that and of home users. But I have
not enough time neither knowledge to bring such tools to community, not
for now at least...

Thank you.

- --
Alessio Gaeta
http://meden.uni.cc


P.S.: let me know if I'm abusing of your time: I'll stop to fill your
mailbox with my (maybe trivial or useless) questions! :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH73yJirbk3DO+UZ0RAsVtAKDTOkj7sYEXWuLE8Nm3zDDI0AVBggCfbXne
403P9PACjW/1n4y128Esnck=
=TyUx
-----END PGP SIGNATURE-----