URL:
https://github.com/SSSD/sssd/pull/432
Title: #432: CACHE_REQ: Better debugging for email conflicts
mzidek-rh commented:
"""
On 11/03/2017 05:41 PM, lslebodn wrote:
On (03/11/17 16:19), mzidek-rh wrote:
>No, I used good example. Your example is the wrong one and would not
trigger the error.
>
There are more ways how you can store users with email to cache.
The most important is that email is lowercased in backed and stored to
nameAlias and not in responder. In theory, you can use even getpwuid.
(I didn't try)
But `sysdb_getpwnam` will find them because it uses filter
`SYSDB_PWNAM_FILTER`
I do not see, how your above sentences are relevant to anything. Why do you
mention getpwuid?
>What do you think will happen if in my example scenario I search for
'getent passwd email2' ? It will return correct results. Do you see why?
It is not about returning correct results. The purpose of ticket is to
inform
about conflicts (or even prevent such conflicts if possible)
The reason why I said that it will return correct results was to
demonstrate that your example was invalid. It would not trigger the
code, so you showing message with username that has no
connection to the email was invalid. You tried to demonstrate how
useless this patch is using that invalid example.
>I already answered it in one of my previous comments, but here I tell
it again. Because in my example email2 (fqdn version
email2(a)ipadomain.test) is just a username.
>Same as your benutzer123 and user123. It will never trigger the error
because they do not conflict with any email address of another user.
>
They have the same email. Just case is different (unless I did a typo)
Therefore lowercased email in "nameAlias" will be the same and will return
two users.
If you search 'by the email', yes. That is what the patch is about. Again,
I fail to see what is your point with that sentence.
>In your example, in order to trigger the error you would have to
search for getent passwd lorem.ipsum(a)jmail.com. Then you would see the
error message telling you that lorem.ipsum(a)jmail.com is is probably
conflicting with another users email or fqdn.
>
As I mentioned about there are more ways how you can store user with email
to sssd cache. The problem is that `sysdb_getpwnam` can return more users
(e.g. `benutzer123` and `user123`) at the same time because lowercased email
stored in "nameAlias" is the same.
Again, if you search by the email address. Yes. Which is why this
patch adds the message. Your point would be valid if the example you
showed was real and the message would print the username that is not
the same as someone else's email. If you now see that it is not the case
and still refer to this, then I really fail to see your point.
The other related problem is that `sysdb_getpwnam` should not indirectly
search by email address. Search by email address should be done only
in `sysdb_search_user_by_upn_res` which explicitly search either by UPN
or by email address.
When you are saying that sysdb_getpwnam should not indirectly search for email
address, do you mean that sysdb_getpwnam should not look for email address
at all? Why? Because I do not think that is the case, and I checked some code
paths, and it looks like we do expect sysdb_getpwnam to also find users by
emails.
Or do you mean that sysdb_getpwnam should not use nameAlias to search
for the email and instead use a new attribute called for example emailAlias?
In that case, how is such change related to this message and this PR/BZ?
We would still hit the issue no matter what attribute is used in the filter,
so it makes sense to print the message.
You mentioned that this PR should be potentially about preventing the issue
with the collisions and not just informing about it. At this point I am still not
sure if you understand what the actual problem is, but let me inform you
that it is not possible to avoid the collisions unless we want to drop the
support for lookup by emails. There is a workaround that will disable
the lookup by email and I document it in the man page with this patch.
IMO the man page change and the debug message do improve the situation.
This PR has 'changes requested' label. Can you please tell me what are
the changes that are requested? Because you said a lot of sentences, but
the only thing that I can see is the vague request/non request for adding the
syslog call (would be good if you confirmed that you want/do not want the syscall).
"""
See the full comment at
https://github.com/SSSD/sssd/pull/432#issuecomment-341809232