#7193 + some tweaks to test sssd.conf::user option #7195
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alexey-tikhonov
force-pushed
the
nonprivileged-tweaks
branch
2 times, most recently
from
7c299df to
b954b51
Compare
|
Since this only happens on f-41 and centos-9 it probably has something to do with the patches in this PR, but so far I can't get SSSD logs from IPA server... |
alexey-tikhonov
force-pushed
the
nonprivileged-tweaks
branch
3 times, most recently
from
50e67a9 to
ed93d8b
Compare
Fixed. |
alexey-tikhonov
force-pushed
the
nonprivileged-tweaks
branch
from
ed93d8b to
9ec8fff
Compare
Most probably it was copy-paste from macro definition.
It was given in 632fc5d several years ago.
Keep all checks of command line options together and slightly reorder for a (hopefully) better readability. Error exit codes updated to: - 1 - bad command line options or config - 2 - no mem - 5 - all kinds of other issues
This will allow to avoid the need for CAP_DAC_OVERRIDE with single addition of supplementary group.
Since db1a919 the only socket in '/private' is an internal SBUS socket.
Previously it was done only for 'sssd_nss' to allow it to write to sssd:sssd owned mem-cache file while running under 'root'. Let's use this approach for all other files to avoid using CAP_DAC_OVERRIDE in run time (in following patches). Primarily rely on systemd to set group, but try to set it manually if (required and) missing at runtime.
Since ec77ec4 mem-cache files aren't tracked as a part of a package anymore so there is no need to keep SSSD_USER ownership of those files.
The only usage was 'sssd-kcm.service', but it was wrong since 'sssd_kcm' should be usable without other SSSD packages being installed (see SSSD#6926)
It will be used by 'monitor' to first read 'sssd.conf' then switch uid/gid before writing 'config.ldb' This is required in case sssd.service::User and sssd.conf::user do not match.
It's already read in `get_monitor_config()`
`sss_ini_get_string_config_value()` is a wrapper around `ini_get_string_config_value()`, whose docs says ``` Returned value needs to be freed after use. ``` But an attempt to free 'const char *' results in discarded-qualifiers warning.
- perform_checks(): log actual owner - sss_confdb_create_ldif(): use SSSDBG_TRACE_LDB
552390a mentioned ``` might be useful e.g. in RPM %post scripts. ``` but it didn't happen. SSSD performs cache upgrade at startup automatically, explicit command doesn't have any use. On the other hand, it can spoil cache files ownership if users used to run 'sssctl' and SSSD do not match. :relnote: sssct `cache-upgrade` command was removed. SSSD performs automatic upgrade at startup when needed.
There are some known issues like SSSD#5536 but those have to be solved differently. Having 'CAP_KILL' in sssd.service doesn't help anyway (and currently isn't used anyhow).
(1) read sssd.conf (should be readable by user that is used to start monitor) (2) switch user to sssd.conf::user (if configured), drop all capabilities (3) write config.ldb This ensures all SSSD components can read config.ldb without capabilities even if (deprecated) sssd.conf::user is used.
:relnote: *IMPORTANT note for downstream maintainers!* This release features significant improvements of "running with less privileges (under unprivileged service user)" feature. There is still a ./configure option '--with-sssd-user=' available that allows downstream package maintainers to choose if support of non-root service user should be built. In case such support is built, a preferred way to configure service user is simply by starting SSSD under this user; for example, using 'User=/Group=' options of systemd sssd.service file. Upstream defaults are to build "--with-sssd-user=sssd" and to install systemd service with "User=/Group=sssd'. In this case, only several helper processes - 'ldap_child', 'krb5_child' and 'selinux_child' - are executed with elevated capabilities (that are now granted using fine grained file capabilities instead of SUID bit). All other SSSD components run without any capabilities. In this scenario it's still possible to re-configure SSSD to run under 'root' (if needed for some reason): besides changing "User/Group=" options, some other tweaks of systemd service files are required. Those tweaks are described in the comments in service files. If SSSD is built "--with-sssd-user=sssd" but configured to run under "root", it's still possible to use a legacy sssd.conf::user option to change a service user at runtime. This requires granting CAP_SET_UID/ CAP_SET_GID capabilities to sssd.service (again, read comments in the service file). User will be changed and all capabilities dropped immediately at startup. There should be no reason to prefer sssd.conf::user option over sssd.service::User option, barring very exotics setups where it's impossible to configure initial service user. Take a note, that this release deprecates sssd.conf::user option and its support might be removed in future releases. Further, doesn't matter if SSSD is built "--with-sssd-user=sssd" or "--with-sssd-user=root", when it's configured to run under "root" (in both cases) it still runs without capabilities, the same way as when it's configured to run under "sssd" user. The only difference is from DAC perspective. Important: owner of /etc/sssd/sssd.conf file (and snippets) should match user configured to start SSSD service. Upstream spec file changes ownership of existing sssd.conf to 'sssd' during package installation for seamless upgrades. Additionally, this release fixes a large number of issues with "socket activation of responder" feature, making it operable out-of-the-box when the package is built "--with-sssd-user=sssd". Please take a note, that user configured to run main sssd.service and socket activated responders (if used) should match (i.e. if sssd.service is re-configured from upstream defaults to 'root' then responders services also should be re-configured). Downstream package maintainers are advised to carefully inspect changes in contrib/sssd.spec.in, src/sysv/systemd/* and ./configure options that this release brings!
Since now SSSD starts and runs under %{sssd_user} by default,
make sure cache files left from previous version are %{sssd_user}:%{sssd_user}
owned.
Since now SSSD starts and runs under %{sssd_user} by default,
make sure config files left from previous version are %{sssd_user}:%{sssd_user}
owned.
'sssd_kcm' doesn't need CAP CHOWN/SET-ID itself but needs to have it in bounding set so that 'krb5_child' run by 'sssd_kcm' can get those capabilities. CAP_DAC_OVERRIDE is used to access sssd.conf and log folder. The latter can be dropped once (if) 'sssd_kcm' is changed to run under 'sssd' user by default. An approach to use 'SupplementaryGroups=' isn't practical here because config files aren't readable by group and changing this in existing setups might be cumbersome. It should be easier to make 'sssd_kcm' to run under 'sssd' user.
User used to run 'sssctl', 'sssd_kcm', etc (typically root) might not match user configured to run SSSD service.
See https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#PIDFile= ``` Note that PID files should be avoided in modern projects. Use Type=notify, Type=notify-reload or Type=simple where possible, which does not require use of PID files to determine the main process of a service and avoids needless forking. ``` SSSD uses "Type=notify"
instead of /var/run. SSSD run under non-privileged user can't write to /var/run. Anyway this file is for internal use only, systemd doesn't need it.
This will also allow to use "SecureBits=noroot" in sssd.service
in sssd.service to avoid processes gaining all capabilities from bounding set during execv() with uid=0/gid=0 (so that, for example, 'sssd_be' runs without capabilities even if "User=root")
so that SSSD built --with-sssd-user=sssd but run under 'root' can get to sssd.conf without capabilities (using "SupplementaryGroups=sssd") sssd.conf still needs to be chown'ed to 'root:root' manually in this case.
For a real device this is handled by udev rule that makes device readable by SSSD. This rule doesn't work with mocked device.
alexey-tikhonov
force-pushed
the
nonprivileged-tweaks
branch
from
9ec8fff to
903f324
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR SSSD is built '--with-sssd-user=sssd' but started with 'sssd.service::User=root'.
And then all system tests are run in this mode, and a set of core tests are also run with "sssd.conf::user=sssd'
See
etc in the logs.