On Thu, 2014-05-22 at 16:00 +0200, Sumit Bose wrote: > On Thu, May 22, 2014 at 09:42:15AM -0400, Simo Sorce wrote: > > On Thu, 2014-05-22 at 15:18 +0200, Sumit Bose wrote: > > > On Thu, May 22, 2014 at 08:49:34AM -0400, Simo Sorce wrote: > > > > On Thu, 2014-05-22 at 10:11 +0200, Sumit Bose wrote: > > > > > Hi, > > > > > > > > > > I would like to use getpwnam() to find the POSIX user for a given > > > > > Kerberos principal. To achieve this I have to change the > > > > > regular-expression we use to split the user name into name and domain > > > > > components because we use '@' as a delimiter here and Kerberos > > > > > principals contain an '@' as well. > > > > > > > > > > My idea is to allow an '@' in the name part so that 'a@b@c' is split > > > > > into the name part 'a@b' and the domain part 'c'. A name containing an > > > > > '@' will then be considered as a Kerberos principal by SSSD and used > > > > > accordingly. If the domain is not known and the Kerberos principal > > > > > should be searched in all known domains a single '@' at the end, e.g. > > > > > 'a@b@' shall indicate that the argument is a Kerberos principal. > > > > > > > > > > I would like to know if you agree with this approach, if you have > > > > > concerns and other suggestions? > > > > > > > > > > As a side node. While looking at this I found some oddities in the > > > > > current regular-expressions. E.g. currently '@' is not allowed in the > > > > > name part, but in the domain part when '@' is the separator. This > > > > > leads > > > > > to a splitting of 'a@b@c' to name 'a' and domain 'b@c'. For AD-style > > > > > names with '\' as a separator '@' is allowed in names, i.e. 'a\b@c' > > > > > will > > > > > be result in name 'b@c' and domain 'a' (so in theory I could use this > > > > > scheme to send a Kerberos principal to SSSD, but for me this looks > > > > > even > > > > > stranger than my suggestion above, it hard to use on the command-line > > > > > and does not solve the case where the domain is not known). I will try > > > > > to fix those inconsistencies as well. > > > > > > > > I don't like this much. > > > > > > > > Instinctively I would say the current scheme should be just fine, if you > > > > pass in name@REALM you get REALM as the domain name. If they match (bar > > > > case), then you search for name as the username. If they do not match > > > > and you end up finding no domain, then we can internally decide to > > > > search all domain using name@REALM as the principal in a ldb_search(). > > > > > > > > Where does this break ? > > > > > > > > Is it possible to have a user foo in domain example.com that has a > > > > principal of [email protected] ? And at the same time also have a user > > > > 'bar' in the same domain ? > > > > Is this the case you are trying to handle ? How likely is it ? > > > > > > no, I think this is quite unlikely. My concern was more related to > > > performance. If we decide that name@REALM is a principal because we > > > didn't find user 'name' in domain 'REALM' we have to iterate over all > > > configured domains and check if there is a user with the given > > > principal. If the domain is known for the principal we cannot only skip > > > the user lookup but can search the given domain directly. The krb5 > > > localauth will be able to give the right domain in all the cases where > > > the user logs in with a fully qualified name or if fully qualified names > > > are used as canonical names. > > > > If we index the principal names, a perfect match search will be quite > > fast, I do not think performance will be a big deal. > > > > In general you will not know the domain from the kerberos side, so I am > > not sure you'd be ever able to pass in the right domain name, I forgot > > the details of the interface though, but if I look at gss_localname() > > the only thing that gets passed in is a gss_name_t wihch is a pure > > kerberos principal in this case. I do not see where you would be able to > > pass in additional information (eg. sssd domain). > > I was thinking of the kuserok case where you get local name and the > principal. > > > > > > > Btw, I was thinking whether we should handle cases where you pass in > > > > things like root/admin@REALM this would require some special mapping > > > > rules ... have you thought about these cases ? > > > > > > This will currently pass the regular expressions splitting the input. > > > But yes, we have to decide how to handle them when searching for > > > principals. > > > > At least it is easy to skip a regular search as '/' is not a valid > > character in a user name, so we can skip straight to the 'principal > > mangling code'. > > > > Btw, I was thinking we could use some trick to tell sssd we only want a > > principal -> user resolution (vs a standard getpwnam), as there are at > > least 2 characters we can abuse to deal with it. For example encasing > > the principal name within ':' chracters as in :[email protected]: would > > be quite clear (or maybe: ':princ:[email protected]'). > > > > I am just not sure we want to abuse the nsswitch interface that way. > > Ok, I will continue with the scheme you proposed. If we run into issues > it would be possible to enhance it later without invalidating the > previous work. > > > > > Bonus question, are we going to try to store these entries in the fast > > cache ? > > yes, it's the response of a getpwnam() call. Is there a reason not to > store it?
well, :princ:[email protected] is not really a valid user name, now is it ? So I am not sure the fast cache should see this stuff. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
