[sssd PR#693][opened] SYSDB: Fall back to the MPG result of getgrgid search if the non-MPG search for override doesn't match anything
by jhrozek
URL: https://github.com/SSSD/sssd/pull/693
Author: jhrozek
Title: #693: SYSDB: Fall back to the MPG result of getgrgid search if the non-MPG search for override doesn't match anything
Action: opened
PR body:
"""
Commit cf4f5e031ecbdfba0b55a4f69a06175a2e718e67 changed the logic of
getgrgid (and getpwnam, so far this patch only touches getgrgid) in the
sense that if looking up a GID in a MPG domain, the code checks if the GID
was overriden and if yes, it mandates that the overriden GID resolves to
a group by falling back to a non-MPG search.
This breaks the following use-case:
$ ipa idoverrideuser-add --uid=13133 --gidnumber=13133 'Default Trust View' user@domain
Most importantly, I'm on the fence about whether the current behaviour is
a bug or not. In general, I would have expected that if a primary GID is
overriden, you more or less break the MPG model, and then it's fair from
SSSD to make sure the GID number resolves to an entry. But apparently our
users were relying on the old behaviour where you can set the primary GID
with an override and then still resolve the primary group by ID to the user
entry.
So the patch in the PR is just a quick hack which sort of falls back to using
the user entry as the group if the overriden GID doesn't resolve to anything.
Should we support this use-case at all? Should we maybe limit it to
cases where the UID and GID are the same?
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/693/head:pr693
git checkout pr693
4 years, 1 month
[sssd PR#596][opened] [CONFDB]:[RFE] Add "enabled" option to domain section
by amitkumar50
URL: https://github.com/SSSD/sssd/pull/596
Author: amitkumar50
Title: #596: [CONFDB]:[RFE] Add "enabled" option to domain section
Action: opened
PR body:
"""
Upstream Request:
Instead of enabling domains using the "domains" option in [sssd]
section we could have [domain/*] option "enabled". This would allow
admins to configure and enable domain in the same snippet file.
This Fix would be submitted in 2 patches:
Patch-1(This Patch):
- Introduces 'enabled' option in domain section
- Introduces 'CONFDB_DOMAIN_ENABLED' variable to retrieve enabled value
from confdb
- Code to call start_service() routine only for domains having enabled=1
Patch-2(Upcoming):
- Would remove 'domains' option from sssd section.
- Would remove corresponding code to parse 'domains' option
- Providing a check that atlest One domain have enabled option set.
Resolves: https://pagure.io/SSSD/sssd/issue/3735
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/596/head:pr596
git checkout pr596
4 years, 1 month
[sssd PR#1001][opened] ssh: fix matching rules default
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/1001
Author: sumit-bose
Title: #1001: ssh: fix matching rules default
Action: opened
PR body:
"""
Before the ssh_use_certificate_matching_rules option was added the ssh
responder returned ssh keys derived from all valid certificates. Since
the default of the ssh_use_certificate_matching_rules option is
'all_rules' in a case where no matching rules are defined all
certificated will be filtered out and no ssh keys are returned.
The intention of the default was to allow the same same certificates
which are allowed in the PAM responder for authentication. The missing
default matching rule which is currently use by the PAM responder if no
other rules are available is added by this patch.
There might still be a small regression in case certificates without the
extended key usage (EKU) clientAuth were used for ssh. In this case
'ssh_use_certificate_matching_rules = no_rules' or a suitable matching
rule must be added to the configuration.
Related to https://pagure.io/SSSD/sssd/issue/4121
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/1001/head:pr1001
git checkout pr1001
4 years, 1 month
Question regarding domain-local groups filtering
by Samuel Cabrero
Hi,
I found the filtering of domain-local groups was implemented after a
change to query the group memberships from the LDAP server of the
domain the user belongs to instead of the global catalog, which had the
side effect of retrieving the DLGs of trusted domains [1].
This DLGs are cached but treated as non-POSIX gruops (no gid number
assigned and not returned), after the commit implementing the filter
[2].
I have found an use case where not filtering domain-local groups would
be useful. If you want to use group memberships in sudo rules to allow
temporary sudo access, the replication latency of global groups is very
high and can take up to 15 minutes, but using domain local groups
replication is done in less than one minute.
Would you willing to accept a patch adding a new parameter to disable
the filtering of DLGs?
Regards,
[1] https://pagure.io/SSSD/sssd/issue/2161
[2] https://pagure.io/SSSD/sssd/issue/2178
--
Samuel Cabrero / SUSE Labs Samba Team
GPG: D7D6 E259 F91C F0B3 2E61 1239 3655 6EC9 7051 0856
scabrero(a)suse.com
scabrero(a)suse.de
4 years, 1 month