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

Jakub Hrozek jhrozek at redhat.com
Thu May 22 09:07:18 UTC 2014


On Thu, May 22, 2014 at 10:11:54AM +0200, Sumit Bose wrote:
> Hi,
> 
> I would like to use getpwnam() to find the POSIX user for a given
> Kerberos principal.

In general I'm fine with what you propose, but I wonder why is it easier
to use getpwnam() and not a special library call, like we have for sid-to-name
lookups? Did you want to avoid having to link the localauth plugin with
a third party library (like sss_nss_idmap) ?

> 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'.

Yes, I think we were asked to allow e-mail addresses as username in the
past anyway.

> 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.

Currently we only support domain names that contain alphanumeric ASCII
characters, dashes and underscores anyway, at least those defined in the
sssd.conf. I'm not sure if the same limitation is also imposed on
subdomains.

But still, what about only allowing the '@' in the name part? I don't
think we would break backwards compatibility, I doubt anyone is using a
subdomain with '@' in the name.



More information about the sssd-devel mailing list