Bug 1389318

Sorry, but how is this a gssproxy problem?  That is, what are you trying to do that this breaks, and what would you expect to happen?

Well, rpc.svcgssd is integrated with libnfsidmap, so according to /etc/idmap.conf settings, UID/GID is translated to name and back.

With gssproxy, according to gp_export.c, function gp_export_creds_linux, translation is hardcoded to use getpwnam_r.

So if you use static user mapping or your own plugin to libnfsidmap, it is working with legacy rpc.svcgssd and it is not working with gssproxy as it relies on NSS. NSS for instance, does not handle cross-realms.

Moreover, it does not make much sense to me that one part of user mapping is still done via rpc.idmapd and libnfsidmap, the other part of user mapping should be handled by NSS (which is the case with gssproxy instead of rpc.svcgssd).

Can you explain what you mean with: "NSS for instance, does not handle cross-realms." ?

How do you handle cross-realm environments ?

Unfortunately libnfsidmap is not thread-safe and does not properly handle mapping of Ids when they are properly handled via SSSD and similar processes.

Can you provide more context on what kind of mappings do you have and whatr situations you need to handle ?

Cross-realms: I mean we use principals like:
hejtman@META, hejtman, hejtman@EINFRA and so on.
While hejtman@META and hejtman@EINFRA maps to some user id (e.g. 10000), I need hejtman to map to root id (i.e., 0). So stripping realm does not provide correct result. 

Moreover, I have mapping also for principal like: nfs/hejtman@META, or even nfs/$HOSTNAME@META. I have no idea how to set up this correctly with gssproxy.

With rpc.svcgssd, we have a plugin into libnfsimdap that uses separate passwd file that contains whole principals not just usernames.

gssproxy uses gss_localname, which ties into the krb5 notion of a mapping.  At a first approximation, the kerberos mappings could look something like:

[realms]
  ADMIN.META = {
    auth_to_local = RULE[1:$1](hejtman)s/^.*/root/g
    auth_to_local = DEFAULT
  }
  META = {
    # doesn't capture the hostname case but I have no idea what user that maps to
    auth_to_local = RULE[2:$1;$2](^nfs;.*$)s/nfs;//g
    auth_to_local = DEFAULT
  }

We are not aware of any cases where the mappings are not sufficiently powerful, and are more likely to improve deficiencies therein than to link libnfsidmap.

Using the mentioned plugin, I map nfs/$HOSTNAME@META to particular UID. This cannot be done with new mapping method.

(In reply to Lukas Hejtmanek from comment #7)
> Using the mentioned plugin, I map nfs/$HOSTNAME@META to particular UID. This
> cannot be done with new mapping method.

How not?  You'd just do something like:

auth_to_local = RULE[2:$1;$2](^nfs;.*$)s/^.*$/symbolic_name/g

wouldn't you?  What am I missing?

Can I have potentially hundreds of such auth_to_local rules? I am also not quite sure, I want to change /etc/krb5.conf on demand (these rules are not static).

Still, idmapd uses libnfsidmap, gssproxy would use different approach? I don't think this is systematic approach.

Moreover, what about users in ldap? libnfsidmap allows to use ldap backend for storing user's principals. This is something unsupported in future?

(In reply to Lukas Hejtmanek from comment #9)
> Can I have potentially hundreds of such auth_to_local rules? I am also not
> quite sure, I want to change /etc/krb5.conf on demand (these rules are not
> static).

What are you doing that needs hundreds of rules?  Can you given an example?

> Still, idmapd uses libnfsidmap, gssproxy would use different approach? I
> don't think this is systematic approach.

libnfsidmap is, as stated above, generally bad and we are unlikely to use it.  If there are specific deficiencies in the proposed approach we will try to address them (within reason, of course).

> Moreover, what about users in ldap? libnfsidmap allows to use ldap backend
> for storing user's principals. This is something unsupported in future?

I don't really know what you're asking - krb5 can use LDAP as a backing store already, which is unrelated to gssproxy or NFS.

Hello,

sorry for delay. 

We are using several Kerberos realms. Logins of the same user in different realms can be different. 

We have all these enteries in /etc/passwd-nfs4 file (no running service is need, more fault tolerant). 

xhejtman@META:x:3000000:15000000
xhejtman@EGI:x:3000000:15000000
lukas.MUNI.CZ:x:3000000:15000000
xhejtman@VOCE:x:3000000:15000000
xhejtman@EINFRA:x:3000000:15000000
nfs/xhejtman@EGI:x:3000000:15000000
nfs/xhejtman@META:x:3000000:15000000
nfs/xhejtman@EINFRA:x:3000000:15000000
nfs/xhejtman@VOCE:x:3000000:15000000
nfs/lukas.MUNI.CZ:x:3000000:15000000
nfs/anubis.ics.mni.cz.CZ:x:3000000:15000000

How do you want to do this via just few rules if we have like 3000 users?

One more thing. One colleague pointed out, that we have also cases like:

xhejtman@META:x:3000000:15000000
xhejtman@EGI:x:3000001:15000000

i.e., the same name does not map to the same UID among realms. This is the case when single NFS server offers several file systems and several name spaces.

Not sure how this can be solved via mapping or nssswitch plugin.

Simo, I assume it's still the case that you don't want libnfsidmap in gssproxy?

a) I do not see the use case, gss-proxy can map users via gss_localname() and krb5 facilities, so why would we want to add it ?

... however, assuming there is a decent reason ...

b) have they fixed it to be thread safe ?

c) how would you "choose" to use it ?


To answer the mapping questions:

You can use the same /etc/passwd-nfs4 on the system as /etc/passwd and auth-to-local to map the various realms to exactly those names you have there. IE each user is mapped to a "fully qualified name" like xhejtman@META and that is the name saved in the nsswitch database.

For LDAP you can use nsswitch with sssd (supports multiple domains) or nss-ldapd (if you really insist).

If you have many entries and you want to use local files but do not want to change krb5.conf every time you can use a nsswitch module that saves to a local database, and a simple rule that maintains the REALM part intact, then all you need to do is make sure user names are qualified with the full realm in this database.

Closing since we haven't heard back on #c14.