On Tue, 02 Sep 2025 at 12:41:19 +0200, Gioele Barabucci wrote:
On 02/09/25 03:23, Marco Trevisan wrote:
If a module is added to a new database, dh-nss generates a script that
does not check for the presency in all the listed databases and may just
accept if a service is in at least one database. [...] if a service file is:
passwd: files systemd sss
group: files systemd sss
shadow: files sss
systemd won't ever be added to the shadow db.
In the case you are describing, dh-nss is doing the right thing in not
adding the `systemd` module to the `shadow` DB.
I can understand your position on this, but after looking at #1118640 I
disagree, and I would like to ask whether you would be willing to
reconsider.
The rationale behind
this is: "the fact that the `systemd` module is mentioned in
nsswitch.conf means that the sysadmin knew about the `systemd` module.
I think it's closer to something subtly different:
The fact the systemd module is mentioned in nsswitch.conf means that the
sysadmin (and/or the integration glue) means that the sysadmin knew
about the systemd module *as it existed in the past*. But I don't think
that's the same as the sysadmin knowing about the systemd module *as it
is now*: these modules' functionality can evolve over time, and a
decision that was correct at the time can become incorrect.
For example in #1118640, before systemd 249, it was 100% correct to have
libnss-systemd listed in only the passwd and group databases, because it
only knew how to synthesize passwd and group records. But, after systemd
249, the desired state changed: now that userdbd and therefore
libnss-systemd can synthesize shadow and gshadow records, it became
desirable to add that module to those databases too (and in particular
gdm3 v49 won't work if that isn't done, #1116563).
For the more commonly hooked hosts database (libnss-myhostname,
libnss-mdns, etc.), this subtlety doesn't matter, because for a module
that can only resolve hosts records, "listed in any one database" is
equivalent to "listed in every relevant database" anyway. But this does
matter for the passwd/group/shadow/gshadow family, because they serve
closely-related data (particularly the passwd/shadow and group/gshadow
pairings), so it can be important for them to be consistent.
The fact that it does not appear in line for the shadow DB means that
the sysadmin decided not to enable it for the shadow DB, so I will
leave it alone".
I don't think that's a conclusion that can be drawn from the available
data. If the sysadmin installed their system with Debian 11, at that
time, libnss-systemd only implemented the passwd and group databases, so
there was no real decision to be made about whether to configure it for
the shadow and gshadow databases: the obviously correct answer was "no,
don't" because at the time, libnss-systemd wouldn't return any
information for them.
But then the sysadmin upgrades to Debian 12 (or 13 or up), and now the
upgraded libnss-systemd *does* implement shadow and gshadow. We can't
infer from the sysadmin's previous actions with Debian 11 what
configuration they would have done if they had installed Debian 12 or
newer, because the situation has changed, and their decision can (and
IMO should) change to match it.
It seems reasonable to me for our guess at the answer to be: they would
have wanted their Debian 11 system, when upgraded to Debian 12, to gain
Debian 12's default behaviour.
Also, if the packager decides to move the position of the service, the
orded won't be adapted.
This is a slightly different issue
I agree that the relative positioning of modules within one database's
configuration line is a different issue, and harder to solve in dh-nss.
However, it's also less critical: the order only matters if the same
entity appears in more than one database, for example the same user
appearing more than once in files, systemd, sss and/or ldap, with
contradictory information.
that is better solved upstream by
the (upcoming?) introduction of nsswitch.conf dropins (see
<https://bugzilla.suse.com/show_bug.cgi?id=1215487>)
That would be a great improvment to see, but until/unless it exists, we
need to do our best to have a working OS with the feature-set we have.
Is there a glibc upstream feature request for nsswitch.conf.d? I
couldn't find anything on <https://sourceware.org/bugzilla/>.
smcv
