Bug 1713352
| Summary: | Implicit files domain gets activated when no sssd.conf present and sssd is started. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Niranjan Mallapadi Raghavender <mniranja> |
| Component: | sssd | Assignee: | Tomas Halman <thalman> |
| Status: | CLOSED ERRATA | QA Contact: | sssd-qe <sssd-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.6 | CC: | atikhono, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, thalman, tscherf |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | sync-to-jira | ||
| Fixed In Version: | sssd-1.16.4-29.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-31 19:44:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Niranjan Mallapadi Raghavender
2019-05-23 13:04:10 UTC
We should only autostart the domain if --enable-files-domain is passed through configure and fail if there are no domains configured and --disable-files-domain was selected. There is default configuration in our code. This default configuration doesn't respect --(disable|enable)-files-domain configure switch. Here are PRs for upstream and sssd-1-16 https://github.com/SSSD/sssd/pull/824 https://github.com/SSSD/sssd/pull/825 (In reply to Tomas Halman from comment #3) > There is default configuration in our code. This default configuration > doesn't respect --(disable|enable)-files-domain configure switch. > Here are PRs for upstream and sssd-1-16 > This assumption is not correct. The configure time option --enable-files-domain just change the default value of the option enable_files_domain. and this option prepends an implicit domain with “id_provider=files” before any explicitly configured domains. > https://github.com/SSSD/sssd/pull/824 > https://github.com/SSSD/sssd/pull/825 You would need to revert patches from upstream issue https://pagure.io/SSSD/sssd/issue/3339 to get return code ERR_MISSING_CONF. And PRs caused failures to sssd integration tests because upsgream#3339 was fixed to increase code coverage. The upstream change was done intentionally because previously sssd could not be started without valid sssd.conf. There was an attempt in 1.14.0 to do that with proxy prvider https://pagure.io/SSSD/sssd/c/59744cff6edb106ae799b2321cb8731edadf409a but it caused bunch of unrelated problems & AVCs ... The upstream issue #3339 fixed solved starting without sssd.conf with files provider in 1.15.3 And such change is in rhel7 since 2017-Oct-23 >Expected results: > >sssd should not start with implicit_files domains when no sssd.conf is present. Sure we could "rename" implicit_files domain to something else if sssd was compiled without --enable-files-domain and /etc/sssd/sssd.conf does not exist. But sssd should start without sssd.conf. I would recommend to close this BZ as not bug. (In reply to Lukas Slebodnik from comment #4) > (In reply to Tomas Halman from comment #3) > > There is default configuration in our code. This default configuration > > doesn't respect --(disable|enable)-files-domain configure switch. > > This assumption is not correct. Why? Default config (both old `SSSD_FALLBACK_CONFIG_LDIF` and current `confdb_ldif_from_ini_file:fallback_cfg` in master) really ignores `--(disable|enable)-files-domain`. So, imho, this statement is correct. Another question if this is something that needs to be changed... > The configure time option --enable-files-domain just change the default > value of the option enable_files_domain. In case of exisiting sssd.conf, right. But this option is forced to `true` in case of absent sssd.conf > You would need to revert patches from upstream issue > https://pagure.io/SSSD/sssd/issue/3339 > to get return code ERR_MISSING_CONF. Not necessary. sssd refuses to start with empty domain list anyway. So there is no need in explicit ERR_MISSING_CONF to achieve goal stated in comment 2. > The upstream change was done intentionally because previously sssd could not > be started without valid sssd.conf. ... > But sssd should start without sssd.conf. This is key point: do you remember rationale for this statement? What is the reason to allow start of sssd when user didn't provide any domain and explicitly turned "defalt files domain" off (which is quite evident misconfiguration)? I see that there is not agreement of what we want to achieve. In my opinion this bug is valid for rhel7 because we should not change behaviour of SSSD. In rhel8 and fedora sssd is AFAIK compiled with --enable-files-domain and sssd will start without config file. With --disable-files-domain (rhel7) it fails with quite descriptive error that there is not configured provider and config file is missing (not readable). So we don't have to put the error code for missing config back. (In reply to Tomas Halman from comment #6) > I see that there is not agreement of what we want to achieve. > > In my opinion this bug is valid for rhel7 because we should not change > behaviour of SSSD. In rhel8 and fedora sssd is AFAIK compiled with > --enable-files-domain and sssd will start without config file. > > With --disable-files-domain (rhel7) it fails with quite descriptive error > that there is not configured provider and config file is missing (not > readable). So we don't have to put > the error code for missing config back. FWIW, I agree that without the nsswitch.conf to back up the files domain, it has no use. (In reply to Alexey Tikhonov from comment #5) > > The upstream change was done intentionally because previously sssd could not > > be started without valid sssd.conf. > ... > > But sssd should start without sssd.conf. > > This is key point: do you remember rationale for this statement? > > What is the reason to allow start of sssd when user didn't provide any > domain and explicitly turned "defalt files domain" off (which is quite > evident misconfiguration)? Well, seems there is no significant reasons at the moment. * master: * 31e08f3 * 15cc1e4 Yes , Adding qa_ack. Tomáš, should we chase acks for this one? (In reply to Michal Zidek from comment #12) > Tomáš, should we chase acks for this one? Ok, it got automatically acked :) * `sssd-1-16` * e48cdfb69b43964d5472bdf011af59343c719a06 - TESTS: adapt tests to enabled default files domain * 5b571efa60f8ce86089772fdd43555174692d0d2 - CONFDB: Files domain if activated without .conf Versions:
libsss_sudo-1.16.4-32.el7.x86_64
sssd-krb5-common-1.16.4-32.el7.x86_64
sssd-proxy-1.16.4-32.el7.x86_64
sssd-1.16.4-32.el7.x86_64
libsss_idmap-1.16.4-32.el7.x86_64
python-sssdconfig-1.16.4-32.el7.noarch
sssd-common-1.16.4-32.el7.x86_64
sssd-common-pac-1.16.4-32.el7.x86_64
sssd-ldap-1.16.4-32.el7.x86_64
sssd-dbus-1.16.4-32.el7.x86_64
python-sss-1.16.4-32.el7.x86_64
sssd-ad-1.16.4-32.el7.x86_64
sssd-kcm-1.16.4-32.el7.x86_64
sssd-winbind-idmap-1.16.4-32.el7.x86_64
libsss_certmap-1.16.4-32.el7.x86_64
libsss_nss_idmap-1.16.4-32.el7.x86_64
sssd-client-1.16.4-32.el7.x86_64
libsss_autofs-1.16.4-32.el7.x86_64
sssd-krb5-1.16.4-32.el7.x86_64
libsss_simpleifp-1.16.4-32.el7.x86_64
sssd-ipa-1.16.4-32.el7.x86_64
sssd-tools-1.16.4-32.el7.x86_64
Check there is no sssd.conf present
[root@ipaqavmf ~]# ls -l /etc/sssd
total 0
drwx--x--x. 2 sssd sssd 6 Sep 29 18:11 conf.d
start sssd
[root@ipaqavmf ~]# systemctl restart sssd
Job for sssd.service failed because the control process exited with error code. See "systemctl status sssd.service" and "journalctl -xe" for details.
[root@ipaqavmf ~]# systemctl status sssd
● sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-10-14 10:15:19 EDT; 12s ago
Process: 29754 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4)
Main PID: 29754 (code=exited, status=4)
Oct 14 10:15:19 ipaqavmf.idmqe.lab.eng.bos.redhat.com systemd[1]: Starting System Security Services Daemon...
Oct 14 10:15:19 ipaqavmf.idmqe.lab.eng.bos.redhat.com sssd[29754]: SSSD couldn't load the configuration database [2]: No such file or directory.
Oct 14 10:15:19 ipaqavmf.idmqe.lab.eng.bos.redhat.com systemd[1]: sssd.service: main process exited, code=exited, status=4/NOPERMISSION
Oct 14 10:15:19 ipaqavmf.idmqe.lab.eng.bos.redhat.com systemd[1]: Failed to start System Security Services Daemon.
Oct 14 10:15:19 ipaqavmf.idmqe.lab.eng.bos.redhat.com systemd[1]: Unit sssd.service entered failed state.
Oct 14 10:15:19 ipaqavmf.idmqe.lab.eng.bos.redhat.com systemd[1]: sssd.service failed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1053 |