Systemd provides an option for allocating DynamicUsers
which we want to use in NixOS to harden service configuration.
However, we discovered that the user wasn't allocated properly
for services. After some digging this turned out to be, of course,
a cache inconsistency problem.
When a DynamicUser creation is performed, Systemd check beforehand
whether the requested user already exists statically. If it does,
it bails out. If it doesn't, systemd continues with allocating the
user.
However, by checking whether the user exists, nscd will store
the fact that the user does not exist in it's negative cache.
When the service tries to lookup what user is associated to its
uid (By calling whoami, for example), it will try to consult
libnss_systemd.so However this will read from the cache and tell
report that the user doesn't exist, and thus will return that
there is no user associated with the uid. It will continue
to do so for the cache duration time. If the service
doesn't immediately looks up its username, this bug is not
triggered, as the cache will be invalidated around this time.
However, if the service is quick enough, it might end up
in a situation where it's incorrectly reported that the
user doesn't exist.
Preferably, we would not be using nscd at all. But we need to
use it because glibc reads nss modules from /etc/nsswitch.conf
by looking relative to the global LD_LIBRARY_PATH. Because LD_LIBRARY_PATH
is not set globally (as that would lead to impurities and ABI issues),
glibc will fail to find any nss modules.
Instead, as a hack, we start up nscd with LD_LIBRARY_PATH set
for only that service. Glibc will forward all nss syscalls to
nscd, which will then respect the LD_LIBRARY_PATH and only
read from locations specified in the NixOS config.
we can load nss modules in a pure fashion.
However, I think by accident, we just copied over the default
settings of nscd, which actually caches user and group lookups.
We already disable this when sssd is enabled, as this interferes
with the correct working of libnss_sss.so as it already
does its own caching of LDAP requests.
(See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd)
Because nscd caching is now also interferring with libnss_systemd.so
and probably also with other nsss modules, lets just pre-emptively
disable caching for now for all options related to users and groups,
but keep it for caching hosts ans services lookups.
Note that we can not just put in /etc/nscd.conf:
enable-cache passwd no
As this will actually cause glibc to _not_ forward the call to nscd
at all, and thus never reach the nss modules. Instead we set
the negative and positive cache ttls to 0 seconds as a workaround.
This way, Glibc will always forward requests to nscd, but results
will never be cached.
Fixes #50273
Could also move kdc.conf, but this makes it inconvenient to use command line
utilities with heimdal, as it would require specifying --config-file with every
command.
Allow switching out kerberos server implementation.
Sharing config is probably sensible, but implementation is different enough to
be worth splitting into two files. Not sure this is the correct way to split an
implementation, but it works for now.
Uses the switch from config.krb5 to select implementation.
Several service definitions used `mkEnableOption` with text starting
with "Whether to", which produced funny option descriptions like
"Whether to enable Whether to run the rspamd daemon..".
This commit corrects this, and adds short descriptions of services
to affected service definitions.
Some modules of cloud-init can cope with a network not immediately
available (notably, the EC2 module), but some others won't retry if
network is not available (notably, the Cloudstack module).
network.target doesn't give much guarantee about the network
availability. Applications not able to start without a fully
configured network should be ordered after network-online.target.
Also see #44573 and #44524.
DBus seems to resolve user IDs directly via glibc, circumventing nscd. In more
advanced setups this leads to user's coming from LDAP or SSSD not being
resolved by the dbus system bus daemon. The effect for such users is, that all
access to the system bus (e.g. busctl or nmcli) is denied.
Adding the respective NSS modules to the service's environment solves the issue
the same way it does for nscd.
DBus daemon now loads its config from /run/current-system/dbus.
Reloading the daemon makes it re-read that file and catch the updates
after a system upgrade.
perlPackages.TextWrapI18N: init at 0.06
perlPackages.Po4a: init at 0.47
jade: init at 1.2.1
ding-libs: init at 0.6.0
Switch nscd to no-caching mode if SSSD is enabled.
abbradar: disable jade parallel building.
Closes #21150
The following changes are included:
1) install user unit files from upstream dbus
2) use absolute paths to config for --system and --session instances
3) make socket activation of user units configurable
There has been a number of PRs to address this, so this one does the
bare minimum, which is to make the functionality available and
configurable but defaults to off.
Related PRs:
- #18382
- #18222
(cherry picked from commit f7215c9b5b)
Signed-off-by: Domen Kožar <domen@dev.si>
It appears that packageOverrides no longer overrides aliases, so
aliases like
dbus_tools = self.dbus.out;
dbus_daemon = self.dbus.daemon;
now use the old, non-overriden version of dbus. That seems like a
pretty serious regression in general, but for this particular problem,
I've fixed it by replacing dbus_daemon by dbus.daemon and dbus_tools
by dbus.
The docstring for the `services.dbus.packages` configuration option only
mentioned one directory, but the implementation actually looked for DBus
config files in four separate places within the target packages. This
commit updates the docstring to reflect the actual implementation
behaviour.
