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@b@c' is split
into the name part 'a@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@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.
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.