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] enable mymachines
(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: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
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' of '24'. 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.
> 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. nss-mymachines simply reports the uids/gids that a container manager (specifically: nspawn) took possession of. It is hence just a messenger here. It just reports what other programs took possession of, and if there's anything to criticize with the allocation logic of those programs it should be brought up with those tools. Hence, I am pretty sure it's relatively riskless to enable nss-mymachines: if there are UID/GID conflicts then the trouble is elsewhere already, as the UID/GIDs are allocated multiple times already. Note that nspawn is relatively careful when picking ranges. It does check NSS first (though as it needs 64K UIDs at a time, not all, but at least the base one). Since there's no better logic for checking for UID/GID ownership I think it's essential that every allocation shows up in NSS. Or to say this differently: enabling nss-mymachines certainly helps *avoiding* UID/GID conflicts by registering them in the official database, it certainly doesn't *create* them.
This can be dealt with in the setup package once it has taken ownership of /etc/nsswitch.conf.
Simo, after reviewing Lennart's reply in comment #10, do you still have concerns about nss_mymachines?
We had quite useful discussions with Lennart about UID/GID mapping and latest advances (also related to homed, etc...). There is a new interface being proposed that will allow modules to report which ranges are "reserved" without having to return bogus data when a module "owns" a UID but no account has been yet created for the UID. Until that is done just asking getpwuid() if a uid is free or not won't really yield the guarantees Lennart mentioned about for nspawn, and given nspawn is not a required service by default it would be more conservative to wait until interfaces to reserve ranges are available IMO. If you can distinguish between new intall and upgrades I guess you could test this on new installs, but I would really not do this on upgrades.
This is obsolete since /etc/nsswitch.conf ownership moved to authselect, see https://src.fedoraproject.org/rpms/glibc/c/cadee80b1316bc264db044180e20dc1e671ed1ea?branch=rawhide