On (13/04/16 13:25), Lukas Slebodnik wrote:
>On (13/04/16 12:55), Lukas Slebodnik wrote:
>>On (13/04/16 12:43), Sumit Bose wrote:
>>>On Wed, Apr 13, 2016 at 10:39:44AM +0200, Lukas Slebodnik wrote:
>>>> On (12/04/16 11:03), Sumit Bose wrote:
>>>> >Hi,
>>>> >
>>>> >I'm working on adding certificates to overrides and came across some
>>>> >issues with the local overrides. The main cause was that instead you
>>>> >searching the original object in the cache, the DN of the object was
>>>> >constructed. This failed for users form sub-domain which have the
>>>> >fully-qualified name in the DN and not only the short name. Additionally
>>>> >users with mixed-case names where not found in case-insensitive domains
>>>> >which can e.g. with the AD provider and the Administrator user from AD.
>>>> >
>>>> >The first patch contains a new integration test which tests the
>>>> >mixed-case user name. Unfortunately it is currently not possible to test
>>>> >the sub-domain case.
>>>> >
>>>> >The second patch replaces the DN based lookup with a proper search. Imo
>>>> >calls like sysdb_user_dn() to construct a DN should only be used when
>>>> >adding new entries but newer to look up entries. Here always proper
>>>> >searches should be used. And as long as the search uses index attributes
>>>> >it will not be much more expensive than the DN based lookup because
>>>> >afaik the ldb index tables are kept in memory.
>>>> >
>>>> >The third patch makes sure that the tools are aware of the flat name and
>>>> >the SID of the master domain if this information is available in the
>>>> >cache. This might currently not be needed explicitly but helps to avoid
>>>> >some irritating debug messages about a missing flat name when generating
>>>> >fully qualified names.
>>>> >
>>>> >Finally the last patch fixes the output of sub-domain users which
>>>> >already have a fully-qualified name where no additional domain component
>>>> >must be added.
>>>> >
>>>> >bye,
>>>> >Sumit
>>>> 
//snip

>>>> >+    /* check if the name already contains domain part */
>>>> >+    ret = sss_parse_name(mem_ctx, domain->names, name, &dummy_domain, 
>>>> >NULL);
>>>> >+    if (ret == ERR_REGEX_NOMATCH) {
>>>> >+        DEBUG(SSSDBG_TRACE_FUNC,
>>>> >+              "sss_parse_name could not parse domain from [%s]. "
>>>> >+              "Assuming it is not FQDN.\n", name);
>>>> >+    } else if (ret != EOK) {
>>>> >+        DEBUG(SSSDBG_TRACE_FUNC,
>>>> >+              "sss_parse_name failed [%d]: %s\n", ret, 
>>>> >sss_strerror(ret));
>>>> >+        return NULL;
>>>> >+    }
>>>> >+
>>>> >+    if (dummy_domain != NULL) {
>>>> >+        talloc_free(dummy_domain);
>>>> >+        DEBUG(SSSDBG_TRACE_FUNC, "Name is already fully qualified.\n");
>>>> >+        fqname = talloc_strdup(mem_ctx, name);
>>>> >+        if (fqname == NULL) {
>>>> >+            DEBUG(SSSDBG_CRIT_FAILURE, "talloc_strdup failed.\n");
>>>> >+            return NULL;
>>>> >+        }
>>>> >+
>>>> >+        return fqname;
>>>> >+    }
>>>> I think it would be better to check ret for EOK
>>>> rather then checking dummy_domain. The variable dummy_domain
>>>> will be everytime set if ret is EOK.
>>>
>>>Are you sure, I thought if the name does not contain a domain part
>>>sss_parse_name() returns EOK and set the returned domain name to NULL?
>>>At least this is how I understand the parse_name_plain() name test.
>>>
>>Ahh,
>>you are right.
>>I was looking into unit tests for sss_parse_name
>>and I didn't notice different re_expression.
>>sss_override should work with any regex.
>>
>>ACK
>>
>>http://sssd-ci.duckdns.org/logs/job/41/16/summary.html
>>
>master:
>* 32dd0dd34193a7566d83adf6845f5194decc3304
>* e45096aead1d2e2b8f8b2b386b420c5f62ad07d3
>* 3a8b5ccf7c27b72054e1d8b3ab355cb1e28efda9
>* e6e2d1575ac7feb3494649f94ef51ef13cbdce48
>

sssd-1-13:
* 279a9cd4e56522590f844a3ddde2235098065133
* baadb2467521b4da61e9c205d9549c750fad3eae
* a6c3abd6b9b23477ad6008852371937d16679778
* f3f312492a925e2efe1457a7cb8ab5b459eaef68

LS
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]

Reply via email to