[sssd PR#475][opened] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
by jhrozek
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
Action: opened
PR body:
"""
NOTE: This fix doesn't address the segfault, only the condition that led
to it. I would prefer to track the segfault and the search base issues
separately
NOTE2: I didn't have much time to test this PR yet. I'm mostly submitting
it to get feedback
Please see the full commit message below. I'm really confused about this
issue mostly because it seems we've had this bug for quite some time but did
not see it. I would be glad if somebody helps me understand if iterating
over all domains and adding all domains that are not yet present in the
ad_id_ctx->ad_options->sdap_id_ctx->sdom list is correct or not
The commit message follows:
Resolves: https://pagure.io/SSSD/sssd/issue/3594
Previously, sdap_domain_subdom_add() was called when a new ad_id_ctx was
being instantiated in the AD subdomains provider. The
sdap_domain_subdom_add() call iterates over all known subdomains and adds a
sdap_domain instance for every domain that is not present in an existing
sdap_domain list.
This is problematic for the AD subdomains provider e.g in this scenario
found by downstream ticket #3594:
- there is a domain child1.sssdad.com the sssd is joined to
- the subdomain provider auto-discovers ssdad_tree.com and
sssdad.com, in this order (which is important). The list of
sss_domain_info objects is updated in this order, too
- for each domain, ad_subdom_ad_ctx_new() is called. This function
creates a new ad_id_ctx and calls sdap_domain_subdom_add() to
add an sdap_domain object into the sdap_id_ctx. The
sdap_domain_subdom_add() call adds both domains to the list
-- for the sssdad_tree subdomain is is ok, because subsequent
calls only use the first sdap_domain object which is
ssdad_tree.com (remember, order is important)
-- for the sssdad.com domain, ssdad_tree.com is added first,
which then causes all searches in the sssdad.com to have a
search base from ssdad_tree.com
Because the sdap_domain instance in sdap_id_ctx should not be a list, but a
single domain, this patch adds a utility function that creates an
sdap_domain instance for a single subdomain instance.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
6 years, 2 months
[sssd PR#237][opened] providers: Move hostid from ipa to sdap
by hvenev
URL: https://github.com/SSSD/sssd/pull/237
Author: hvenev
Title: #237: providers: Move hostid from ipa to sdap
Action: opened
PR body:
"""
This just makes sss_ssh_knownhostsproxy work. There is no support for hostgroups (although hostgroups in `ipa` should continue working).
I've been using this for a few days with the `ldap` and `krb5` providers and I haven't noticed any regressions. I haven't tested `ipa` and `ad` but all tests seem to pass.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/237/head:pr237
git checkout pr237
6 years, 2 months
Fleet Commander: design changes due to the drop of DAC_OVERRIDE capability
by Fabiano Fidêncio
People,
Let's start with the context of this email:
https://bugzilla.redhat.com/show_bug.cgi?id=1536854
So, seems that even without knowing that, I've relied on CAP_DAC_OVERRIDE
in order to have the Fleet Commander integration working as expected and in
the implementation details of this feature.
The desktop profiles are stored in a dir like:
/var/lib/sss/deskprofile/$domain/$user/$profile.
Currently, the way I've been creating those are:
$domain = 755 (root:root)
$user = 600 ($user:$user_group)
$profile = 600 ($user:$user_group)
Now, as mentioned in the bugzilla linked in this email, the current code
fails with an EACCES.
With all this background, I'd like to discuss what's the best approach to
take. I've opened a PR (https://github.com/SSSD/sssd/pull/498) which makes
everything work again, but does the following changes:
$domain = 755 (root:root) -- NO changes here
$user = 770 ($user:root) --> changed from 600 ($user:$user_group)
$profile = 660 ($user:root) --> changed from 600 ($user:$user_group)
This is one way to solve the issue suggested at
https://bugzilla.redhat.com/show_bug.cgi?id=1536854#c5.
Another suggestion, also mentioned in the bugzilla, would be to only
fchown()/fchmod() the files/dirs *after* all the operations we do are over.
Is there any other suggestion? Whatever comes out of this discussion will
be used to update the feature's design page accordingly.
Best Regards,
--
Fabiano Fidêncio
6 years, 2 months