Bug 1577250

Summary: systemd-libs modifies /etc/nsswitch.conf in scriptlets which conflicts with authselect on Fedora 28
Product: [Fedora] Fedora Reporter: Edgar Hoch <edgar.hoch>
Component: systemdAssignee: systemd-maint
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 29CC: akos.ladanyi, Bert.Deknuydt, jsynacek, lnykryn, msekleta, nmavrogi, pbrezina, s, systemd-maint, terje.rosten, thomas, zbyszek, zing
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-27 22:37:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Edgar Hoch 2018-05-11 14:38:25 UTC
Description of problem:

systemd-libs modifies /etc/nsswitch.conf in postinstall script.
This conflicts with authselect which checks if /etc/nsswitch.conf is modified and refuses changes if it detects changes by other programs.

The new concept of authselect is - if I had understand it right - that only authselect should modify these files that it was designed to configure.

As a consequence, packages in Fedora 28 shouldn't change /etc/nsswitch.conf in there scriptslets.



# rpm -q --scripts systemd-libs.x86_64
postinstall scriptlet (using /bin/sh):


if [ -f /etc/nsswitch.conf ] ; then
        # sed-fu to add myhostanme to hosts line
        grep -v -E -q '^hosts:.* myhostname' /etc/nsswitch.conf &&
        sed -i.bak -e '
                /^hosts:/ !b
                /\<myhostname\>/ b
                s/[[:blank:]]*$/ myhostname/
                ' /etc/nsswitch.conf &>/dev/null || :

        # remove mymachines from passwd and group lines of /etc/nsswitch.conf
        # https://bugzilla.redhat.com/show_bug.cgi?id=1284325
        # https://meetbot.fedoraproject.org/fedora-meeting/2015-11-25/fesco.2015-11-25-18.00.html
        # To avoid the removal, e.g. add a space at the end of the line.
        grep -E -q '^(passwd|group):.* mymachines$' /etc/nsswitch.conf &&
        sed -i.bak -r -e '
                s/^(passwd:.*) mymachines$/\1/;
                s/^(group:.*) mymachines$/\1/;
                ' /etc/nsswitch.conf &>/dev/null || :

        # Add [!UNAVAIL=return] after resolve
        grep -E -q '^hosts:.*resolve[[:space:]]*($|[[:alpha:]])' /etc/nsswitch.conf &&
        sed -i.bak -e '
                /^hosts:/ { s/resolve/& [!UNAVAIL=return]/}
                ' /etc/nsswitch.conf &>/dev/null || :

        # Add nss-systemd to passwd and group
        grep -E -q '^(passwd|group):.* systemd' /etc/nsswitch.conf ||
        sed -i.bak -r -e '
                s/^(passwd|group):(.*)/\1: \2 systemd/
                ' /etc/nsswitch.conf &>/dev/null || :
fi

# check if nobody or nfsnobody is defined
export SYSTEMD_NSS_BYPASS_SYNTHETIC=1
if getent passwd nfsnobody &>/dev/null; then
   test -f /etc/systemd/dont-synthesize-nobody || {
       echo 'Detected system with nfsnobody defined, creating /etc/systemd/dont-synthesize-nobody'
       mkdir -p /etc/systemd || :
       : >/etc/systemd/dont-synthesize-nobody || :
   }
elif getent passwd nobody 2>/dev/null | grep -v 'nobody:[x*]:65534:65534:.*:/:/sbin/nologin' &>/dev/null; then
   test -f /etc/systemd/dont-synthesize-nobody || {
       echo 'Detected system with incompatible nobody defined, creating /etc/systemd/dont-synthesize-nobody'
       mkdir -p /etc/systemd || :
       : >/etc/systemd/dont-synthesize-nobody || :
   }
fi



authselect shows the following error

# authselect check
[error] [/etc/nsswitch.conf] is not a symbolic link!
[error] [/etc/nsswitch.conf] was not created by authselect!
Current configuration is not valid. It was probably modified outside authselect.


... and denies setting a configuration from profiles (without --force option)

# authselect select sssd with-encryptfs
[error] [/etc/nsswitch.conf] is not a symbolic link!
[error] [/etc/nsswitch.conf] was not created by authselect!
[error] Unexpected changes to the configuration were detected.
[error] Refusing to activate profile unless those changes are removed or overwrite is requested.

Some unexpected changes to the configuration were detected.
Use --force parameter if you want to overwrite these changes.




Version-Release number of selected component (if applicable):
systemd-libs-238-7.fc28.1.x86_64
systemd-libs-238-7.fc28.1.i686


How reproducible:
Always

Comment 1 Terje Røsten 2018-05-13 12:41:43 UTC
I just tried to kickstart install F28, it ended in 


:50:15,702 INF packaging: Configuring (running scriptlet for): systemd-238-7.fc28.1.x86_64 1524088869 34a2a5895230fe401cde36001d0d1ef19511bc
cc1cc9d460dbf9891101d8dd2c
13:50:15,727 INF packaging: Configuring (running scriptlet for): systemd-238-7.fc28.1.x86_64 1524088869 34a2a5895230fe401cde36001d0d1ef19511bc
cc1cc9d460dbf9891101d8dd2c
13:50:15,750 INF packaging: Configuring (running scriptlet for): systemd-238-7.fc28.1.x86_64 1524088869 34a2a5895230fe401cde36001d0d1ef19511bc
cc1cc9d460dbf9891101d8dd2c
13:50:15,777 ERR dnf.rpm: Non-fatal <unknown> scriptlet failure in rpm package systemd
13:50:19,551 Level 8 dnf: RPM transaction over.

Some error in systemd scriptles.

Looking at the scriplets for systemd:

https://src.fedoraproject.org/cgit/rpms/systemd.git/tree/systemd.spec#n472

I am really horrified, there are lots and lots of random commands, "fixing"
things all over the place.  

This is insane. 

For example/etc/fstab and /etc/nsswitch.conf in %post script is just plain madness.

What kind of development process and review accepts such things?

Comment 2 Edgar Hoch 2018-05-13 17:49:51 UTC
(In reply to Terje Røsten from comment #1)
> I just tried to kickstart install F28, it ended in 
> 
> 
> :50:15,702 INF packaging: Configuring (running scriptlet for):
> systemd-238-7.fc28.1.x86_64 1524088869 34a2a5895230fe401cde36001d0d1ef19511bc
> cc1cc9d460dbf9891101d8dd2c
> 13:50:15,727 INF packaging: Configuring (running scriptlet for):
> systemd-238-7.fc28.1.x86_64 1524088869 34a2a5895230fe401cde36001d0d1ef19511bc
> cc1cc9d460dbf9891101d8dd2c
> 13:50:15,750 INF packaging: Configuring (running scriptlet for):
> systemd-238-7.fc28.1.x86_64 1524088869 34a2a5895230fe401cde36001d0d1ef19511bc
> cc1cc9d460dbf9891101d8dd2c
> 13:50:15,777 ERR dnf.rpm: Non-fatal <unknown> scriptlet failure in rpm
> package systemd
> 13:50:19,551 Level 8 dnf: RPM transaction over.
> 
> Some error in systemd scriptles.

Your error has nothing to do with this bug report. You may check bug report 1565425. Try to exclude package wine-systemd in your kickstart configuration, and install it (and wine) after you have bootet the new installation if you need it.

Comment 3 Jan Synacek 2018-05-14 11:40:18 UTC
(In reply to Edgar Hoch from comment #0)
> authselect shows the following error
>
> ...
> The new concept of authselect is - if I had understand it right - that
> only authselect should modify these files that it was designed to configure.
> ...
> 
> # authselect check
> [error] [/etc/nsswitch.conf] is not a symbolic link!
> [error] [/etc/nsswitch.conf] was not created by authselect!
> Current configuration is not valid. It was probably modified outside
> authselect.

I fully agree that changing /etc/nsswitch.conf from the systemd's %post script is an ugly hack and should not be there. However, it's been there for quite some time now. What I find hilarious and even laughable is that someone somewhere decides that, suddenly, only this old tool with the new behavior we now provide is able to modify this file now. That's just ridiculous.

Just my opinion.

Comment 4 Nikos Mavrogiannopoulos 2018-11-02 08:49:08 UTC
I incorrectly switched the component. Switching back.
btw. Jan, I do not think the comment above is productive or towards a solution in any way.

Comment 5 Pavel Březina 2018-11-02 09:51:22 UTC
Everyone can modify it, however authselect will then refuse to do changes if change outside authselect was detected unless --force parameter is set.

This is one of unfortunate bumps of this transition since we started getting feedback only from f28 when we switch to authselect by default and not in f27 where it was available but no one actually tried it. So there are packages that are in conflict with authselect, we are trying to be in touch with few maintainers/developers (including this systemd module).

And we plan to work on a way to unify how packages writes to nsswitch.conf so it does not conflict with authselect and is actually made easier for the packages:
https://github.com/pbrezina/authselect/issues/77

Comment 6 Zbigniew Jędrzejewski-Szmek 2018-11-04 10:59:50 UTC
We all dislike the %post scriptlets very much ;) Nevertheless, the configuration of various modules provided by systemd is necessary in nsswitch.conf for various functionality to work. Some of it is niche or just nice-to-have, but other parts are widely used and important. So just skipping those changes to configuration is not an option.

We (speaking for various systemd developers here) made various attempts over the years to remove them, but unsuccessful so far. In the past the "proper" solution appeared to be to add various systemd nss modules to the base configuration in glibc. With authselect, the proper solution might be different. Either way, please work with us to provide those modules in the basic configuration, and we'll be very very happy to drop the scriptlets.

Comment 7 Pavel Březina 2018-11-06 10:30:30 UTC
All authselect profiles currently contains 'systemd' module in passwd and group maps.

As said we plan to provide an authselect command that would modify nsswitch.conf, something like 'authselect nsswitch-mod passwd --add systemd ...' (do not take this for granted I have not started working on a design yet) and make it probably in F30 a system-wide change so all packages that needs to touch nsswitch.conf are converted. This will simplify the scriptlets for package maintainers and it will make it compatible with authselect and at the same time it will not force users to use authselect.

Authselect conflicts with systemd scriptlets during update. If the system is already managed by authselect, systemd seems to touch the nsswitch.conf when systemd package is upgraded. Do you actually need to run it during upgrade? Wouldn't it be sufficient to run it only during first installation?

Comment 8 Ben Cotton 2019-10-31 19:14:39 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
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 '29'.

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 29 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.

Comment 9 Ben Cotton 2019-11-27 22:37:44 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.