Red Hat Bugzilla – Bug 1284325
glibc: add nss_mymachines to /etc/nsswitch.conf
Last modified: 2017-07-25 18:51:44 EDT
Currently systemd.rpm has a %post scriptlet that adds 'mymachines' at the end of passwd, group, and hosts lines. This is error prone, and can mangle local changes to that file. Please consider adding 'mymachines' to the default /etc/nsswitch.conf file provided installed by glibc.rpm.
The mymachines nss module provides resolution of the hostnames of local containers, and also user and group names when user namespaces are used (see http://www.freedesktop.org/software/systemd/man/nss-mymachines.html). It does nothing when systemd-machined is not running or no machines are registered with it. It has been enabled by default in all systems having systemd, i.e. probably almost all, without reported problems, so should be fairly safe.
If an nss module cannot be loaded, it is silently skipped. So it is OK to add it without introducing a dependency on the systemd package.
Created attachment 1097573 [details]
(In reply to Zbigniew Jędrzejewski-Szmek from comment #0)
> It has been enabled by default in all systems having
> systemd, i.e. probably almost all, without reported problems, so should be
> fairly safe.
Could you qualify that? I don't see the user/group part it in installations based on Fedora 22.
Why does nss_mymachines have to call execvp in some cases? This is generally very bad practice for a NSS module.
> I don't see the user/group part it in installations based on Fedora 22.
Yes, the user/group part has been only present so far in rawhide builds. The module itself has been scripted into nsswitch.conf for about a year though. We will not add the user/group part into F23 or lower.
> Why does nss_mymachines have to call execvp in some cases?
I don't think it does. The binary is linked to libsystemd which uses sd_bus_open_system, which uses sd_bus_start, which can use execvp, but with a different address than sd_bus_open_system uses. So the call to execvp is there but should never be used in the code reachable from nss-mymachines.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> I don't think it does. The binary is linked to libsystemd which uses
> sd_bus_open_system, which uses sd_bus_start, which can use execvp, but with
> a different address than sd_bus_open_system uses. So the call to execvp is
> there but should never be used in the code reachable from nss-mymachines.
Please minimize these dependencies first, so that we are on the safe side. This includes stripping down the list of needed DSOs as well (which also affects nss_myhostname).
https://github.com/systemd/systemd/pull/2008 reduces linked DSOs significantly.
There still a few libraries linked, that could in principle be removed. But this would probably require changes to current architecture, where the nss modules use libsystemd to query the system.
I noticed that nss_mymachines does not work with nscd out of the box (bug 1285267).
So apparently nss_mymachines user and group support weould interfere with FreeIPa and Samba install where it is common to use high IDs, the same can be said of other identity management systems using LDAP where arbitrary UIDs can be used.
Enabling this module by default would break all thes systems in very bad ways, especially if nscd is configured as nscd is very dumb in the way it caches and cannot understand conflict between modules.
Before something like this can be used in Fedora system we should, at the very least, go through a Feature change process, and involve all stakeholders that have a long experience with dealing with IDs and id-mapping in the system.
If systemd is adding this by default in F23 I'll have to open a bug and make it stop as this may break the domain controller role.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.
More information and reason for this action is here:
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.