Bug 1713352 - Implicit files domain gets activated when no sssd.conf present and sssd is started.
Summary: Implicit files domain gets activated when no sssd.conf present and sssd is st...
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tomas Halman
QA Contact: sssd-qe
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-23 13:04 UTC by Niranjan Mallapadi Raghavender
Modified: 2019-10-15 06:36 UTC (History)
8 users (show)

Fixed In Version: sssd-1.16.4-29.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Niranjan Mallapadi Raghavender 2019-05-23 13:04:10 UTC
Description of problem:

Implicit files domain gets activated when no sssd.conf present and sssd is started. 

Version-Release number of selected component (if applicable):
sssd-1.16.2-13.el7_6.8.x86_64

How reproducible:


Steps to Reproduce:
1.install sssd
2.Remove any /etc/sssd.conf if available. 
3.start sssd

Actual results:

root     24337     1  9 18:28 ?        00:00:00 /usr/sbin/sssd -i --logger=files
root     24338 24337 11 18:28 ?        00:00:00 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
root     24339 24337 18 18:28 ?        00:00:00 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
root     24341  8315  0 18:28 pts/1    00:00:00 ps -ef


Expected results:

sssd should not start with implicit_files domains when no sssd.conf is present. 

Additional info:

Comment 2 Jakub Hrozek 2019-05-30 13:19:12 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.

Comment 3 Tomas Halman 2019-06-03 13:14:57 UTC
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

Comment 4 Lukas Slebodnik 2019-06-03 19:39:04 UTC
(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.

Comment 5 Alexey Tikhonov 2019-07-10 15:10:39 UTC
(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)?

Comment 6 Tomas Halman 2019-07-15 08:44:27 UTC
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.

Comment 7 Jakub Hrozek 2019-07-15 12:42:21 UTC
(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.

Comment 8 Alexey Tikhonov 2019-07-18 15:01:18 UTC
(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.

Comment 9 Jakub Hrozek 2019-07-22 18:37:20 UTC
* master:
  * 31e08f3
  * 15cc1e4

Comment 11 Niranjan Mallapadi Raghavender 2019-08-14 09:54:23 UTC
Yes , Adding qa_ack.

Comment 12 Michal Zidek 2019-09-19 10:13:16 UTC
Tomáš, should we chase acks for this one?

Comment 13 Michal Zidek 2019-09-19 10:16:34 UTC
(In reply to Michal Zidek from comment #12)
> Tomáš, should we chase acks for this one?

Ok, it got automatically acked :)

Comment 14 Pavel Březina 2019-09-20 08:36:14 UTC
* `sssd-1-16`
  * e48cdfb69b43964d5472bdf011af59343c719a06 - TESTS: adapt tests to enabled default files domain
  * 5b571efa60f8ce86089772fdd43555174692d0d2 - CONFDB: Files domain if activated without .conf

Comment 16 Niranjan Mallapadi Raghavender 2019-10-14 14:15:49 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.