URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains Action: opened
PR body: """ This ptach is valid only for SSSD-1-13. It adds value 'ALL' to sudoRule attribute "sudoUser". So if we have case insensitive domain such sudo rule will be work for right users.
Resolves: https://fedorahosted.org/sssd/ticket/3203
----
This is simple patch for solving the ticket. Another solution is backport pbrezina patches what I didn't try yet. If you prefer backport please tell me. """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
celestian commented: """ It's time for little explanation.
SSSD (version 1.13) is able to find properly sudoRule. But sudoUser and login name can differ. This simple patch adds value ALL to sudoUser attribute of proper sudoRules.
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-251873720
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
fidencio commented: """ On Thu, Oct 6, 2016 at 7:56 AM, celestian notifications@github.com wrote:
It's time for little explanation.
SSSD (version 1.13) is able to find properly sudoRule. But sudoUser and login name can differ. This simple patch adds value ALL to sudoUser attribute of proper sudoRules.
Hey Petr. I've failed to understand why adding ALL to sudoUser will fix the problem with case-insensitive domains. Can you elaborate a bit more here?
Also, you mentioned backporting Pavel's patches. According to the bug description the issues are different in the different branches. So, do you think backporting any patch could actually solve the issue? If yes, which are those patches that would have to be backported? Backporting, IMO, is always better in case the patches are not too intrusive.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SSSD/sssd/pull/39#issuecomment-251873720, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG4esiTu2UE37hzGbEEsERCOGy0VrqGks5qxI2ZgaJpZM4KO8bG .
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-251898047
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
celestian commented: """ Hi Fabiano,
I wrote about it a bit with @jhrozek a I discussed it with @pbrezina today. Unfortunately on separate channels.
Resume:
1. (sssd-1-13) We are able to find proper sudoRules but login name could defer from sudoUser attribute. For examle you can have sudoUser = Administrator@domain, but login name is administrator@domain. This patch fixes it. If we found proper sudoRule we add value 'ALL' to the sudoUser attribute and return it via responder. So login name administator@... goes down well with 'ALL' value. How @pbrezina said just a while ago it is not sufficient fix because sudoRules work with netgroups too and my solution doesn't => I need fix it better.
2. There is patch set from @pbrezina which enables 'cache_req' for sudo responder. This patch set handles the issue 1. in right way but we don't use 'cache_req' in sssd-1-13 almost. So we are not about to back port it right now.
3. (sssd-1-14) We get login name (administrator@...) but we are not able to find proper sudoRules because there could be in other form (Administator@...). For that case I would like to ensure that we search user in both attributes -- name and nameAlias. And this will be in another PR. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-251921140
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
pbrezina commented: """ The patch that should fix this is: 61913b8f0d1ba54d82640500d7486fac5f72b030 Unfortunately it is written on top of cache_req refactoring in sudo responder which is not in 1.13 so unless we want to backport all those patches we need to write it from scratch.
The problem in 1.14 is caused by fully qulified names in cache patches as far as we know. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-251929154
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
jhrozek commented: """ On Thu, Oct 06, 2016 at 03:51:05AM -0700, Pavel Březina wrote:
The patch that should fix this is: 61913b8f0d1ba54d82640500d7486fac5f72b030
Well, didn't we establish that master was also broken, just the other way around?
Unfortunately it is written on top of cache_req refactoring in sudo responder which is not in 1.13 so unless we want to backport all those patches we need to write it from scratch.
I'm sorry, but I'm not a big fan of rebasing all that in the stable branch, mostly because the code was never released outside Fedora and enterprise users tend to find many more bugs with their strange configurations..so maybe a couple of months in the future, when the code hits RHEL-7.4, but I think it's too early.
The problem in 1.14 is caused by fully qulified names in cache patches as far as we know.
Yes and no, we do use the right qualification, just always lowercased. We need to use both cases also in master.
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-251938477
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
pbrezina commented: """ On 10/06/2016 01:42 PM, Jakub Hrozek wrote:
On Thu, Oct 06, 2016 at 03:51:05AM -0700, Pavel Březina wrote:
The patch that should fix this is:
61913b8f0d1ba54d82640500d7486fac5f72b030
Well, didn't we establish that master was also broken, just the other way around?
Broken, yes. With the same result but different cause (although similar). We should probably create a separate ticket for it so it doesn't get messy.
Unfortunately it is written on top of cache_req refactoring in sudo
responder which is not in 1.13 so unless we want to backport all those patches we need to write it from scratch.
I'm sorry, but I'm not a big fan of rebasing all that in the stable branch, mostly because the code was never released outside Fedora and enterprise users tend to find many more bugs with their strange configurations..so maybe a couple of months in the future, when the code hits RHEL-7.4, but I think it's too early.
I agree.
The problem in 1.14 is caused by fully qulified names in cache patches
as far as we know.
Yes and no, we do use the right qualification, just always lowercased. We need to use both cases also in master.
Yes.
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-251948777
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
celestian commented: """ Hi,
I have question on cache_req_recv(): https://github.com/SSSD/sssd/blob/master/src/responder/common/responder_cach... ``` errno_t cache_req_recv(TALLOC_CTX *mem_ctx, struct tevent_req *req, struct ldb_result **_result, struct sss_domain_info **_domain, char **_name) ``` How you can see the function has three return parameters. Is there any connection between _result and _name?
I assume that _result is whole data set and _name could be only name from this data set. What I see (in implemenation), _name is created like ``` name = talloc_strdup(mem_ctx, state->cr->data->name.lookup); ``` So we take it from state->cr, and it is connected to input data by this definition: ``` struct cache_req_state { /* input data */ struct tevent_context *ev; struct resp_ctx *rctx; struct sss_nc_ctx *ncache; int cache_refresh_percent; struct cache_req *cr;
/* work data */ struct ldb_result *result; struct sss_domain_info *domain; struct sss_domain_info *selected_domain; bool check_next; }; ```
Is there a bug and _name should be created from result?
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-252177317
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
celestian commented: """ Hi,
I have question on cache_req_recv(): https://github.com/SSSD/sssd/blob/master/src/responder/common/responder_cach... ``` errno_t cache_req_recv(TALLOC_CTX *mem_ctx, struct tevent_req *req, struct ldb_result **_result, struct sss_domain_info **_domain, char **_name) ``` How you can see the function has three return parameters. Is there any connection between _result and _name?
I assume that _result is whole data set and _name could be only name from this data set. What I see (in implemenation), _name is created like ``` name = talloc_strdup(mem_ctx, state->cr->data->name.lookup); ``` So we take it from state->cr, and it is connected to input data by this definition: ``` struct cache_req_state { /* input data */ struct tevent_context *ev; struct resp_ctx *rctx; struct sss_nc_ctx *ncache; int cache_refresh_percent; struct cache_req *cr;
/* work data */ struct ldb_result *result; struct sss_domain_info *domain; struct sss_domain_info *selected_domain; bool check_next; }; ```
Is there a bug and _name should be created from result?
Explanation why am I asking. I see that this function is used for obtaining the user name. It returns (via _name) login name, which is lower cased. But if we look to the _result (it is not used in code now), there is real user name (i.e. Administrator@...).
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-252177317
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
celestian commented: """ Hi,
I have question on cache_req_recv(): https://github.com/SSSD/sssd/blob/master/src/responder/common/responder_cach... ``` errno_t cache_req_recv(TALLOC_CTX *mem_ctx, struct tevent_req *req, struct ldb_result **_result, struct sss_domain_info **_domain, char **_name) ``` How you can see the function has three return parameters. Is there any connection between _result and _name?
I assume that _result is whole data set and _name could be only name from this data set. What I see (in implemenation), _name is created like ``` name = talloc_strdup(mem_ctx, state->cr->data->name.lookup); ``` So we take it from state->cr, and it is connected to input data by this definition: ``` struct cache_req_state { /* input data */ struct tevent_context *ev; struct resp_ctx *rctx; struct sss_nc_ctx *ncache; int cache_refresh_percent; struct cache_req *cr;
/* work data */ struct ldb_result *result; struct sss_domain_info *domain; struct sss_domain_info *selected_domain; bool check_next; }; ```
Is there a bug and _name should be created from result?
Explanation why am I asking. I see that this function is used for obtaining the user name. It returns (via _name) login name, which is lower cased. But if we look to the _result (it is not used in code now), there is real user name (i.e. Administrator@...).
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-252177317
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains
pbrezina commented: """ Not, it is not a bug. The output parameter _name contains a name from the request modified according to rules of the selected domain. I.e. the name that was used to lookup the user. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-252194184
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: edited
Changed field: title Original value: """ RESPONDER: Enable sudoRule in case insen. domains """
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I just pushed new version of patch set. It is inspired by patch set for 1.14. And there is one little difference -- adding fq name for users in ```sudoUser``` attribute.
I tested manually and it works. If it is needed I could add ```src/tests/cmocka/test_sysdb_sudo.c``` but it will differ from 1.14 one.
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-254464629
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
pbrezina commented: """ The patch looks good to me. I'd feel better if we somehow managed to backport patch that solves the fully qualified issue in 1.14 though.
I'm not that sure about simply appending domain qualification to sudoUser attributes. I don't recall all reasons why we did not do it, but it may be dangerous if you do not check the exact source where this users comes from. In theory you can have: ```ldif sudoUser: my-user@domain.com sudoUser: my-user ``` Where `my-user@domain.com` comes from domain that requires fully-qualified names and `my-user` is a local user. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-256619222
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ OK, I understand. I will continue on this PR after resolving #43. And we need fully qualified names from 1.14 for this PR.. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-257553626
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ Setting changes requested to rework the patch to only include the sudoUser and not sudoUserAlias """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-258154386
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I pushed new version.
Note: The patch set for 1.15 (and 1.14) is in new version too. It is possible that it will be needed to make cherry pick of Adding lowercase sudoUser from... again. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-258371317
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ Since we have patch set for 1.15 pushed I will prepare proper cherry picking. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259118455
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
pbrezina commented: """ So what is the current plan here? """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259118986
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I pushed new version, only one difference -- I fix cherry-pick pointer. The patch works without ```sudoUserAlias``` but it still adds fq names to sudoUser. Is it OK? Is there way how to avoid fq names?
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259121334
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ On Tue, Nov 08, 2016 at 04:13:43AM -0800, celestian wrote:
I pushed new version, only one difference -- I fix cherry-pick pointer. The patch works without ```sudoUserAlias``` but it still adds fq names to sudoUser. Is it OK? Is there way how to avoid fq names?
Well, the second patch explicitly qualifies the names, is there a reason to qualify them?
btw I haven't tested this patchset at all yet, do the qualified names work at all?
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259122246
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ Yes, the second patch explicitly qualifies the names. I don't know if there is possibility to add wrong domain to the given user name this way. That's the question.
The reason for doing this is that function ```sudosrv_get_user()``` ask for that type of name. How you can see: ``` # grep 'administrator' *.log
# sssd_scorpion.domain.log: [be_get_account_info] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=administrator] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=administrator)(objectclass=user)(objectSID=*))][DC=scorpion,DC=domain]. [pam_print_data] (0x0100): ruser: administrator@scorpion.domain [sssd[be[scorpion.domain]]] [pam_print_data] (0x0100): ruser: administrator@scorpion.domain
# sssd_sudo.log: [sss_parse_name_for_domains] (0x0200): name 'administrator@scorpion.domain' matched expression for domain 'scorpion.domain', user is administrator [sss_parse_name_for_domains] (0x0200): name 'administrator@scorpion.domain' matched expression for domain 'scorpion.domain', user is administrator [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [administrator] from [scorpion.domain] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/scorpion.domain/administrator] [sudosrv_get_user] (0x0200): Requesting info about [administrator@scorpion.domain] [sudosrv_get_user] (0x0400): Returning info for user [administrator@scorpion.domain] [sss_parse_name_for_domains] (0x0200): name 'administrator@scorpion.domain' matched expression for domain 'scorpion.domain', user is administrator [sss_parse_name_for_domains] (0x0200): name 'administrator@scorpion.domain' matched expression for domain 'scorpion.domain', user is administrator [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [administrator] from [scorpion.domain] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/scorpion.domain/administrator] [sudosrv_get_user] (0x0200): Requesting info about [administrator@scorpion.domain] [sudosrv_get_user] (0x0400): Returning info for user [administrator@scorpion.domain] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [administrator@scorpion.domain] ``` """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259131495
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ On Tue, Nov 08, 2016 at 05:06:41AM -0800, celestian wrote:
Yes, the second patch explicitly qualifies the names. I don't know if there is possibility to add wrong domain to the given user name this way. That's the question.
The reason for doing this is that function ```sudosrv_get_user()``` ask for that type of name. How you can see:
# grep 'administrator' *.log # sssd_scorpion.domain.log: [be_get_account_info] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=administrator] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=administrator)(objectclass=user)(objectSID=*))][DC=scorpion,DC=domain]. [pam_print_data] (0x0100): ruser: administrator@scorpion.domain [sssd[be[scorpion.domain]]] [pam_print_data] (0x0100): ruser: administrator@scorpion.domain # sssd_sudo.log: [sss_parse_name_for_domains] (0x0200): name 'administrator@scorpion.domain' matched expression for domain 'scorpion.domain', user is administrator [sss_parse_name_for_domains] (0x0200): name 'administrator@scorpion.domain' matched expression for domain 'scorpion.domain', user is administrator [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [administrator] from [scorpion.domain] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/scorpion.domain/administrator] [sudosrv_get_user] (0x0200): Requesting info about [administrator@scorpion.domain] [sudosrv_get_user] (0x0400): Returning info for user [administrator@scorpion.domain]
This is only how the DEBUG messages are formatted: 122 DEBUG(SSSDBG_FUNC_DATA, "Requesting info about [%s@%s]\n", 123 name, dom->name);
and:
243 DEBUG(SSSDBG_TRACE_FUNC, "Returning info for user [%s@%s]\n", 244 cmd_ctx->username, dctx->domain->name);
In the cache I can see both administrator@win.trust.test and administrator. But do we need the qualified name? Why?
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259134748
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I pushed only the first patch. I had wrong setup with ```use_fully_qualified_names = True```. But if you set ```False``` the pushed patch is proper solution of this issue. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259174363
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ Are you sure this is enough? Because when the patch is applied, I see that we only match the sudoUser value with the original case. Don't we also need to match the lowercase version of the username?
This is what sssd_sudo searches for: ``` (Thu Nov 10 13:11:01 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=Administrator)(sudoUser=#679800500)(sudoUser=%Group\20Policy\20Creator\20Owners)(sudoUser=%Enterprise\20Admins)(sudoUser=%Domain\20Admins)(sudoUser=%Schema\20Admins)(sudoUser=%Domain\20Users)(sudoUser=%Denied\20RODC\20Password\20Replication\20Group)(sudoUser=%sudogroup)(sudoUser=%Domain\20Users)(sudoUser=+*)))] ```
And this is the rule definition: ``` dn: name=morerule,cn=sudorules,cn=custom,cn=win.trust.test,cn=sysdb cn: morerule dataExpireTimestamp: 1478785266 entryUSN: 65695 name: morerule objectClass: sudoRule originalDN: CN=morerule,OU=sudoers,DC=win,DC=trust,DC=test sudoCommand: /bin/more sudoCommand: /usr/bin/more sudoHost: ALL sudoUser: administrator distinguishedName: name=morerule,cn=sudorules,cn=custom,cn=win.trust.test,cn=s ysdb ```
So """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259675726
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ oops...clicked send to early. I meant to say "So the filter never matches the lowercase sudoUser". """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259675812
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I am sure this is enough. Maybe it is not the most direct solution. I try to explain it:
We have user ```Administrator```, sysdb record looks like (minor items missed): ``` dn: name=Administrator,cn=users,cn=scorpion.domain,cn=sysdb fullName: Administrator gecos: Administrator gidNumber: 342400513 name: Administrator objectClass: user uidNumber: 342400500 objectSIDString: S-1-5-21-2022941956-2492201804-3493196904-500 uniqueID: c153af46-809a-41a0-baa6-de76b587e061 originalDN: CN=Administrator,CN=Users,DC=scorpion,DC=domain entryUSN: 69662 nameAlias: administrator ``` And we have ```lessrule```: ``` dn: name=lessrule,cn=sudorules,cn=custom,cn=scorpion.domain,cn=sysdb cn: lessrule dataExpireTimestamp: 1478853348 entryUSN: 45204 name: lessrule objectClass: sudoRule originalDN: CN=lessrule,OU=sudoers,DC=scorpion,DC=domain sudoCommand: /usr/bin/less sudoHost: ALL sudoUser: Administrator sudoUser: administrator distinguishedName: name=lessrule,cn=sudorules,cn=custom,cn=scorpion.domain,cn= sysdb ```
If we look at ```/var/log/secure```: ``` Nov 11 08:02:59 client sudo: pam_sss(sudo:auth): authentication success; logname=administrator uid=342400500 euid=0 tty=/dev/pts/2 ruser=administrator rhost= user=administrator Nov 11 08:02:59 client sudo: administrator : TTY=pts/2 ; PWD=/home/administrator@scorpion.domain ; USER=root ; COMMAND=/bin/less /etc/resolv.conf Nov 11 08:02:59 client sudo: pam_systemd(sudo:session): Cannot create session: Already running in a session Nov 11 08:02:59 client sudo: pam_unix(sudo:session): session opened for user root by administrator(uid=0) ```
I understand that it is searched by the correct name, but sudo finally accepts a name with lowercase letters. If I remove lowercase name from ```sudoRule``` it doesn't work anymore. I wonder if it is a way to make sudo to work with original login name. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-259897355
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ We discussed this issue with @jhrozek.
I misunderstood the case -- the right is -- user is ```Administrator```, the sudoRule is written for user ```administrator``` on case insensitive domain (typically AD).
Now we can see in logs proper filter: ``` [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=Administrator)(sudoUser=administrator)... ```
And the sudoRule is: ``` dn: name=lessrule,cn=sudorules,cn=custom,cn=scorpion.domain,cn=sysdb cn: lessrule dataExpireTimestamp: 1479136324 entryUSN: 90154 name: lessrule objectClass: sudoRule originalDN: CN=lessrule,OU=sudoers,DC=scorpion,DC=domain sudoCommand: /usr/bin/less sudoHost: ALL sudoUser: administrator distinguishedName: name=lessrule,cn=sudorules,cn=custom,cn=scorpion.domain,cn= sysdb ```
I slightly changed the patch, new version is pushed. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-260339114
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I am afraid there is the same issue as in https://fedorahosted.org/sssd/ticket/3241. The patch will be added soon. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-260886546
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ Apart from fixing ticket #3241, why does sysdb_get_sudo_filter add its own lowercased name and does not add all nameAlias values instead? """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-261255728
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ So, I pushed new version. Now ```sysdb_get_sudo_filter()``` uses ```nameAlias``` values.
(And after pushing #80 I will cherry-pick it to 1.13 too.) """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-261940320
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ ACK, this version works for me. I will run also downstream tests to be sure, but my manual testing passed. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262221752
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ Thanks for CR. After pushing it is important to cherry pick #80 as well. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262524310
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ For some reason the downstream tests are stuck and time out, even with known-good packages. I will keep trying but for downstream's sake I'm going to push the patch based on my manual testing. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262530794
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
lslebodn commented: """ On (23/11/16 06:19), celestian wrote:
Thanks for CR. After pushing it is important to cherry pick #80 as well.
I do not agree. The ticket #3241 was a regression caused by #3203.
This patch should fix #3203 for 1.13 I do not see a reason why we should introduce regression with the patch a fix it with other patch. I would prefer to squash patches together for 1.13 branch.
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262532341
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ regardless of what we choose, the patch for PR #80 does not apply atop this patch, can we have a version that applies to the 1.13 branch, please? """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262536635
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Accepted
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ I pushed new version. The patch is the same plus I added back-ported patch from #80 (with cerry-pick tag). """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262557829
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
lslebodn commented: """ On (23/11/16 08:07), celestian wrote:
I pushed new version. The patch is the same plus I added back-ported patch from #80 (with cerry-pick tag).
NACK to two patches. As I explained it before there is not a reason to introduce regression in one patch and fix in another patch.
Please squash them together. The commit message can contain information about squasing commits
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262582550
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
celestian commented: """ Squashed version pushed. """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262694326
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ ack, this version works for me """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262709744
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ (CI pending) """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262709772
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
jhrozek commented: """ CI: http://sssd-ci.duckdns.org/logs/job/57/35/summary.html sssd-1-13: b6d0b0a14c7f09371cbb2afd0347f6a16fcfc8dd """
See the full comment at https://github.com/SSSD/sssd/pull/39#issuecomment-262723829
URL: https://github.com/SSSD/sssd/pull/39 Author: celestian Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13) Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/39/head:pr39 git checkout pr39
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: -Accepted
URL: https://github.com/SSSD/sssd/pull/39 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Label: +Pushed
sssd-devel@lists.fedorahosted.org
-
fidencio