[sssd PR#577][opened] ipa: Use fqname on selinux_child_setup
by fidencio
URL: https://github.com/SSSD/sssd/pull/577
Author: fidencio
Title: #577: ipa: Use fqname on selinux_child_setup
Action: opened
PR body:
"""
Although there was a comment saying that pam_selinux needs the username
in the same format getpwnam() would return it, it doesn't seem to be
the case anymore.
Just using fqname from selinux_child_setup allows us to have the
expected results.
One difference that I've spotted while doing this patch (which may or
may not be an issue) is that without this patch the output of `semanage
login --list` was always (with or without domain_resolution_order set):
[root@client1 x86_64]# semanage login --list
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
admin staff_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
While now I can see:
[root@client1 x86_64]# semanage login --list
Login Name SELinux User MLS/MCS Range Service
__default__ unconfined_u s0-s0:c0.c1023 *
admin staff_u s0-s0:c0.c1023 *
admin(a)ipa.example staff_u s0-s0:c0.c1023 *
root unconfined_u s0-s0:c0.c1023 *
Resolves:
https://pagure.io/SSSD/sssd/issue/3740
Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com>
NOTE: While I still have to run downstream tests to be sure it won't introduce regressions (although, it didn't in the very simple test that I've performed) ... I'd appreciate a review (even before the results of the tests) in order to have an early understanding of whether this is a valid approach or not.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/577/head:pr577
git checkout pr577
5 years, 4 months
[sssd PR#583][opened] sudo/sysdb regressions
by fidencio
URL: https://github.com/SSSD/sssd/pull/583
Author: fidencio
Title: #583: sudo/sysdb regressions
Action: opened
PR body:
"""
This patch set consists in 3 patches:
- sudo_ldap: fix sudoHost=defaults -> cn=defaults: this is a typo that caused https://pagure.io/SSSD/sssd/issue/3742
- Revert "sysdb custom: completely replace old object instead of merging it": this one caused https://pagure.io/SSSD/sssd/issue/3733
- sysdb_sudo: completely replace old object instead of merging it: As far as I understand, the idea behind cd4590de was to never merged sudo rules. Instead, delete the old one and add the new one. However, doing this all over place caused the regression mentioned above. I've checked the other patches that leaded to this one and seems that keeping the "delete the old one and add the new one" approach may be the cleaner possible way.
@pbrezina, may I ask you to (re)test https://pagure.io/SSSD/sssd/issue/3558 in order to be sure that I won't be adding regressions while trying to fix regressions? Also, I do believe this approach is cleaner than adding a new boolean flag in sysdb_store_custom(), do you agree?
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/583/head:pr583
git checkout pr583
5 years, 4 months
[sssd PR#570][comment] p11_child: add OpenSSL support
by jhrozek
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
jhrozek commented:
"""
> On 30 May 2018, at 12:39, sumit-bose <notifications(a)github.com> wrote:
>
> About /etc/sssd/pki, I'm sorry, I didn't understood you correctly in the first place. You suggested to use a directory based CA store (e.g. TLS_CACERTDIR of OpenLDAP) instead of a file based one (e.g. TLS_CACERT of OpenLDAP). If prefer the file bases one because of do not have run some rehash command to create the needed link in the directory store and you can easy link it to other files based stores like e.g. the IPA one.
>
> Nevertheless we can you /etc/sssd/pki to that the file name will be /etc/sssd/pki/sssd_auth_ca_db.pem. The upcoming file with the CRL will then be /etc/sssd/pki/sssd_auth_crl.pem. And if there is really a need for a directory store we can add e.g. /etc/sssd/pki/ca_certs/.
I tried to suggest TLS_CACERT from the start, I just don’t like putting files in the /etc/sssd directory because if we ever want to have e.g. some different access control to a subset of the files, it’s easier to do if the files are in a directory. And if there are multiple related files (like the CRL you mentioned) it’s cleaner to have them in the same directory.
>
> Do you agree?
Yes, I do.
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393193240
5 years, 4 months
[sssd PR#570][comment] p11_child: add OpenSSL support
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/570
Title: #570: p11_child: add OpenSSL support
sumit-bose commented:
"""
About /etc/sssd/pki, I'm sorry, I didn't understood you correctly in the first place. You suggested to use a directory based CA store (e.g. TLS_CACERTDIR of OpenLDAP) instead of a file based one (e.g. TLS_CACERT of OpenLDAP). If prefer the file bases one because of do not have run some rehash command to create the needed link in the directory store and you can easy link it to other files based stores like e.g. the IPA one.
Nevertheless we can you /etc/sssd/pki to that the file name will be /etc/sssd/pki/sssd_auth_ca_db.pem. The upcoming file with the CRL will then be /etc/sssd/pki/sssd_auth_crl.pem. And if there is really a need for a directory store we can add e.g. /etc/sssd/pki/ca_certs/.
Do you agree?
"""
See the full comment at https://github.com/SSSD/sssd/pull/570#issuecomment-393114540
5 years, 4 months