[SSSD] [RFC] Change default regular-expressions for user names

Simo Sorce simo at redhat.com
Thu May 22 14:10:20 UTC 2014


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 at b@c' is split
> > > > > into the name part 'a at 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 at 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 at b@c' to name 'a' and domain 'b at c'. For AD-style
> > > > > names with '\' as a separator '@' is allowed in names, i.e. 'a\b at c' will
> > > > > be result in name 'b at 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 at 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 at 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 bar at EXAMPLE.COM ? 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 at 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 at 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 :simo at FREEIPA.ORG: would
> > be quite clear (or maybe: ':princ:simo at FREEIPA.ORG').
> > 
> > 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:simo at FREEIPA.ORG 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




More information about the sssd-devel mailing list