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.
bye, Sumit
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.
On Thu, May 22, 2014 at 11:07:18AM +0200, Jakub Hrozek wrote:
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) ?
getpwnam() already provides the needed functionality, i.e. indicates if there is a corresponding user or not and returns the canonical name. Adding another call would just duplicate functionality.
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.
yes, although there is a difference because users won't like to type and additional domain name or an '@' sign at the login prompt. If the email-domain is the same as the DNS-domain used by SSSD it will already work. If it is different from the DNS-domain I think we have to add a new internal variable for the mail-domain. Additionally a mail-domain might related to multiple DNS-domain, e.g. in the case of an AD forest.
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.
yes, my point was that we should not allow them in the domain part (at least not as long as there is no use case :-)
bye, Sumit
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Thu, 2014-05-22 at 11:07 +0200, Jakub Hrozek wrote:
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.
AD does not allows special characters in domain names (nor should IPA as they are DNS names too), so I do not think there is any problem on this point.
Simo.
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 bar@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 ?
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 ?
Simo.
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 bar@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@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.
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.
bye, Sumit
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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 bar@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@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).
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 :simo@FREEIPA.ORG: would be quite clear (or maybe: ':princ:simo@FREEIPA.ORG').
I am just not sure we want to abuse the nsswitch interface that way.
Bonus question, are we going to try to store these entries in the fast cache ?
Simo.
On Thu, May 22, 2014 at 09:42:15AM -0400, Simo Sorce wrote:
Is it possible to have a user foo in domain example.com that has a principal of bar@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@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.
I think the performance hit comes even earlier. If you need to check if name@REALM is a user name in a domain REALM, you need to start N searches for N configured domains and only then you will start searching by the principals.
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 bar@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@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 :simo@FREEIPA.ORG: would be quite clear (or maybe: ':princ:simo@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?
bye, Sumit
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
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 bar@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@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 :simo@FREEIPA.ORG: would be quite clear (or maybe: ':princ:simo@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@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.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Simo Sorce -
Sumit Bose