Authselect conflicts with Atomic model about authselect

[cgwalters]

And I think authselect should do the same thing; just don't delete altfiles if it finds it in the existing config.

[cgwalters]

BTW, Atomic is now Fedora CoreOS.
The SSSD approach is actually going to be problematic for us in the near future as Ignition does some system provisioning in the initramfs where sssd isn't running yet.

In the end, we need to do the sysusers switch.

[cgwalters]

History repeats itself:

https://pagure.io/authconfig/c/78bb70e103907a47bfdcbc2dc1651d64eeb58147?branch=master

[jlebon]

History repeats itself

Hah!

And I think authselect should do the same thing; just don't delete altfiles if it finds it in the existing config.

That was my initial thought, though from what I understand, authselect just ships baked predefined config templates. Though maybe what we can do is:

1. add a new *{if "with-nss-altfiles":altfiles}* to the template, and
2. teach authselect itself to automatically turn that feature on if it detects altfiles in the existing config.

The advantage of this is that we don't have to modify Anaconda, which I think we can all agree is for the best. :) It's also forward compatible with a future in which we no longer use altfiles.

[cgwalters]

teach authselect itself to automatically turn that feature on if it detects altfiles in the existing config.

Ah wow, I see now. authselect ships its own copies of the config files and just blows away whatever is there? That...seems not like a good idea.

Anyways a variant of your suggestion is to enable it if nss-altfiles is installed (exists as a pkg in the rpm database).

[pbrezina]

Do you call authconfig/authselect from your kickstart or does Anaconda call authselect automatically without your will?

Anyway, for purposes of docker/other distros/... it is possible to override profiles shipped by authselect with vendor profile. That way vendor can preserve something (PAM stack and override what needs to be changed (nsswitch). This fits well for your use case and you will also get full control over it so once you will want to get away from altfiles, you can. See: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profiles.5.txt.in.in#L21

Create /usr/share/authselect/vendor/sssd and /usr/share/authselect/vendor/winbind (if needed), create symlinks to /usr/share/authselect/default/$profile and provide your own nsswitch template.

Does this work as a solution for you?

[pbrezina]

Ah wow, I see now. authselect ships its own copies of the config files and just blows away whatever is there? That...seems not like a good idea.

This is the thing. If you want to use authselect, there will be no more manual edits and tries to guess the correct configuration and implementing every use case that is needed. You have profiles that we ship that are based on Fedora defaults, those can be overridden with vendor profiles if you need to ship different defaults. Administrators can provide custom profiles if they need different use case.

[cgwalters]

Anyway, for purposes of docker/other distros/...

Fedora Atomic Host is not a separate distribution. It's a toplevel Edition, along with Workstation and Server. Fedora Atomic Host is Fedora too.

does Anaconda call authselect automatically without your will?

AFAICS, yes. If this problem was just "using authselect via kickstart or running it manually breaks FA{H,W}" it'd be a lot less severe.

[cgwalters]

OK I think it's this bit of code in Anaconda. It's not affecting Atomic Host because we don't include fprintd there.

So...I guess we could add a select altfiles or something to authselect, and change anaconda to select that automatically too if /usr/lib64/libnss_altfiles.so.2 exists in the sysroot?

But it really feels like it'd be better to somehow have fprintd just drop in a file somewhere to say it's enabled by default (if it's installed), and allow admins to do something systemctl mask style that disables it if they don't want it. And then drop the bits in anaconda to auto-enable it; authselect is then only run explicitly.

[jlebon]

And then drop the bits in anaconda to auto-enable it; authselect is then only run explicitly.

That makes sense, but we still want to survive an admin doing authselect select sssd --with-some-feature later on, right? I.e. it seems like we still want something like what we suggested earlier regarding e.g. adding a with-nss-altfiles feature and enabling it by default if we detect nss-altfiles. In that case, even if it gets unconditionally run in Anaconda, we should have a proper config.

[pbrezina]

I looked into the Atomic Host image and there is not SSSD installed by default, just sssd-client libs. I think it would be the best to create a profile specifically for atomic and make Anaconda select it by default, instead of the SSSD profile.

If admin than wants to use SSSD, he will select the sssd profile and configure SSSD correctly. SSSD now support alternative files location with files provider, so altfiles is not strictly needed anymore.

[cgwalters]

I think it would be the best to create a profile specifically for atomic

There isn't (today) just one "atomic". There's Fedora Atomic Host and Fedora Atomic Workstation. The latter is mostly a superset of the former.

Further, we really want to support people doing custom composes with their own package sets. For example, a user may want to make an embedded device using rpm-ostree for transactional updates, but no containers. In fact this use case is part of Fedora IoT.

So let's not special case "atomic" in any way. We may or may not have sssd or fprintd etc. Let's figure out a way to just not overwrite the existence of altfiles.

In the future, this problem will solve itself as rpm-ostree will stop relying on altfiles though.

[cgwalters]

SSSD now support alternative files location with files provider, so altfiles is not strictly needed anymore.

Oh hmm I didn't see this at first. If that's true it'd be convenient. I'm not seeing in a quick perusal of man sssd.conf how to enable it though.

[jhrozek]

The SSSD PR that implements the "altfiles" in SSSD was not merged yet. I'll see what I can do to speed up the review..

[pbrezina]

The SSSD PR that implements the "altfiles" in SSSD was not merged yet. I'll see what I can do to speed up the review..

Ah, I acked it like two months ago. I bumped the thread so you can merge it. Since it may be useful here, please create an update soon.

There isn't (today) just one "atomic". There's Fedora Atomic Host and Fedora Atomic Workstation. The latter is mostly a superset of the former.

Does nsswitch/PAM differ in those two?

So let's not special case "atomic" in any way. We may or may not have sssd or fprintd etc. Let's figure out a way to just not overwrite the existence of altfiles.

Let me clarify authselect mission. Authselect is not authconfig and it will not read existing configuration and make small changes to it. Authselect will only write complete configuration defined by profiles. A profile solves one use case. If there is a requirement for another use case, a new profile can be created. We have some upstream profiles, if they need to be overridden or extended for specific needs of a distro there is a possibility to do it by placing new profile to /usr/share/authselect/vendor. And at last, administrators have options to create their custom profile by placing it in /etc/authselect/custom. Therefore set of supported profiles is easily extendable. You can have whatever configuration you need without coordinating with tools as it was needed with authconfig.

There are few possible solutions to this issue:

1. The best solution is to create a profile for atomic. It can be supported upstream or you can create it as a vendor profile. Since you mentioned that you have atomic kickstart, you can use authselect kickstart command to activate it. You gain complete control over how the resulting configuration look like. It can be changed and there will be no special casing. Users will use authselect in the same way to further modify it and create custom compose.

2. Use SSSD for altfiles. This is a good solution, but it will make official and other composes dependent on SSSD.

3. Another solution is to support altfiles in the sssd profile and again set by your kickstart. This is however not correct solution, since every time you change your required configuration, we will have to special case it, keeping all previous changes there.

4. Not calling authselect in Anaconda for atomic.

[cgwalters]

Does nsswitch/PAM differ in those two?

The only thing we change from the underlying RPM defaults is to inject altfiles which just is a nss thing. Other than that we don't try to carry any deltas.

[cgwalters]

The best solution is to create a profile for atomic....You gain complete control over how the resulting configuration look like.

I don't think we or anyone else really wants the maintenance overhead of that. We basically just want altfiles (for now, until we switch to sysusers).

Use SSSD for altfiles. This is a good solution, but it will make official and other composes dependent on SSSD.

I think that's probably fine for FA{H,W}, particularly because the people who are making more minimal images are unlikely to include authselect in the their images.

[cgwalters]

Not calling authselect in Anaconda for atomic.

Note the current situation (as linked above) is that Anaconda calls it automatically but only if it detects fprintd. Which is going to be a recipie for a lot of confusion since there will be a lot of scenarios where authselect isn't used by default.

If we really want the opinionated defaults here to be defaults, I'd say that anaconda should probably change to unconditionally default to invoking authselect. And the files in the packages (e.g. the nsswitch.conf should gain a comment to the effect: # NOTE: This file is usually overwritten by authselect) or so.

[sgallagher]

If we really want the opinionated defaults here to be defaults, I'd say that anaconda should probably change to unconditionally default to invoking authselect. And the files in the packages (e.g. the nsswitch.conf should gain a comment to the effect: # NOTE: This file is usually overwritten by authselect) or so.

Note that it's being considered that nsswitch.conf should actually be moved to the authselect package. Right now it's maintained by glibc, but that has never been an ideal solution because it also provides the configuration for sudo and autofs. It makes more sense to have this file be owned by the package that maintains it.

I think I agree with both @pbrezina and @cgwalters here; we should probably create Atomic Host and Atomic Workstation default nsswitch configurations for authselect and teach Anaconda to apply them appropriately (by calling authselect unconditionally).

I'm going to CC @M4rtinK and @rvykydal here to bring them into the discussion.

[jlebon]

It looks like this is now affecting Fedora 28 Atomic Workstation Beta. Let's agree on a decision? I'm not a fan of maintaining separate profiles for Atomic variants. I'd prefer the auto-detect based on nss-altfiles being installed, as discussed higher up. Though if using different profiles is the easiest option for now, that's fine too.

[cgwalters]

Haven't tested this yet but how about:

diff --git a/fprintd.spec b/fprintd.spec
index 977e9d3..bd6f3dd 100644
--- a/fprintd.spec
+++ b/fprintd.spec
@@ -28,7 +28,6 @@ Requires:	%{name} = %{version}-%{release}
 # is different, it will be mentioned in the release notes
 Provides:	pam_fprint = %{version}-%{release}
 Obsoletes:	pam_fprint < 0.2-3
-Requires(postun): authselect >= 0.3
 
 Group:		System Environment/Base
 License:	GPLv2+
@@ -66,8 +65,8 @@ rm -f $RPM_BUILD_ROOT/%{_lib}/security/pam_fprintd.{a,la,so.*}
 %find_lang %{name}
 
 %postun pam
-if [ $1 -eq 0 ]; then
-  /bin/authselect disable-feature with-fingerprint || :
+if [ $1 -eq 0 ] && test -x /bin/authselect; then
+  /bin/authselect disable-feature with-fingerprint
 fi
 
 %files -f %{name}.lang

This makes the whole model a lot clearer; authselect is only used explicitly by admins.

[jlebon]

So, looking at the ISO contents, it looks like what pulled in authselect this time isn't fprintd, but realmd-0.16.3-11.fc28.x86_64.

With the impending f28 release, I'd like to propose we make this a rawhide issue only while we discuss things further. I.e. are we OK with reverting the unconditional authselect call in Anaconda for F28?

[jlebon]

Proposal here: rhinstaller/anaconda#1410

[M4rtinK]

Adding @poncovka, who has been handling the Anaconda migration from authconfig to authselect to CC.

[AdamWill]

We can work around this for FAW in the meantime by just dropping fprintd-pam from it, we think: https://pagure.io/workstation-ostree-config/pull-request/81

[AdamWill]

BTW, following up on Colin's point here, it's worth noting the behaviour he describes there is new, it was introduced with the authselect migration. The old code for authconfig (F27 and earlier) was less conditional: anaconda would always call authconfig so long as it was actually present in the installed system at all. It didn't have this "if this is an interactive install run authselect with these magic defaults, if this isn't an interactive install, only do what the kickstart says" conditionalization.

[poncovka]

From the Anaconda point of view, we can extend install classes, so they can define the behaviour of authselect for interactive installations. However, I would prefer to find a better way of enabling the fingerprint authentication.

[pbrezina]

The following script can be used to create vendor profiles, overwriting only nsswitch.conf for both sssd and winbind profiles. This way, if authselect (with sssd or winbind profile) is called from Anaconda, realmd, ipa-client-install, manually, ... will use nsswitch.conf with altfiles.

mkdir -p /usr/share/authselect/vendor
mkdir /usr/share/authselect/vendor/sssd
mkdir /usr/share/authselect/vendor/winbind

FILES="dconf-db dconf-locks fingerprint-auth password-auth postlogin README system-auth"
for FILE in $FILES smartcard-auth ; do
  ln -s /usr/share/authselect/default/sssd/$FILE /usr/share/authselect/vendor/sssd/$FILE
done

for FILE in $FILES ; do
  ln -s /usr/share/authselect/default/winbind/$FILE /usr/share/authselect/vendor/winbind/$FILE
done

cat <<EOM >/usr/share/authselect/vendor/sssd/nsswitch.conf
passwd:     sss files altfiles
group:      sss files altfiles
netgroup:   sss files
automount:  sss files
services:   sss files
sudoers:    files sss

shadow:     files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
hosts:      files dns myhostname

aliases:    files nisplus
bootparams: nisplus [NOTFOUND=return] files
publickey:  nisplus
EOM

cat <<EOM >/usr/share/authselect/vendor/winbind/nsswitch.conf
passwd:     files altfiles winbind
group:      files altfiles winbind

shadow:     files
netgroup:   files
automount:  files
services:   files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
hosts:      files dns myhostname

aliases:    files nisplus
bootparams: nisplus [NOTFOUND=return] files
publickey:  nisplus
EOM

[dustymabe]

where do we stand on this? waiting for feedback? i.e. who is waiting on who?

[pbrezina]

Both anaconda and authselect has given several possible solutions, so we are waiting for the discussion to continue from atomic side.

[dustymabe]

@cgwalters @jlebon - i'd like to remove the workaround we put in rawhide. Can we move this issue forward?

[AdamWill]

+1, I definitely agree with @dustymabe that we should pick a choice and move forward on this, let's not make it one more 'workaround' that lives forever...

[pbrezina]

Patch to support alternative passwd and groups locations with SSSD will be soon available in Fedora (probably today), so it could be used instead of nss altfiles.

[cgwalters]

I don't want to "own" a forked authselect config just to add altfiles. IMO the only sane short term thing is for sssd to grow altfiles suppor as is mentioned above.

The long term solution is definitely coreos/rpm-ostree#49

[jlebon]

@pbrezina Do you have a link to the relevant sssd documentation?

[pbrezina]

https://github.com/SSSD/sssd/blob/master/src/man/sssd-files.5.xml#L67

Example configuration:

[sssd]
config_file_version = 2
services = nss, pam
domains = atomic
user = root

[domain/atomic]
id_provider = files
passwd_files = /etc/passwd, /etc/atomic_passwd
group_files = /etc/group, /etc/atomic_group

[jlebon]

Thanks! I'll try that out.

[jlebon]

I got this working in a rawhide compose with authselect and sssd-common added! Though there are a couple of rough spots.

One, there was an ordering issue between dbus.service and sssd.service which caused bootups to hang. I submitted a patch for that here: https://bugs.freedesktop.org/show_bug.cgi?id=106339. The other was https://pagure.io/SSSD/sssd/issue/3727. We'll also need to tweak rpm-ostree. I opened coreos/rpm-ostree#1354 for that.

[jhrozek]

On 1 May 2018, at 22:58, Jonathan Lebon ***@***.***> wrote: I got this working in a rawhide compose with authselect and sssd-common added! Though there are a couple of rough spots. One, there was an ordering issue between dbus.service and sssd.service which caused bootups to hang. I submitted a patch for that here: https://bugs.freedesktop.org/show_bug.cgi?id=106339. The other was https://pagure.io/SSSD/sssd/issue/3727. We'll also need to tweak rpm-ostree. I opened coreos/rpm-ostree#1354 for that.

I talked to @mzidek-rh about this issue and it doesn’t seem to be too hard to implement. Is this something you would want for the near future? (Just asking for prioritization..)

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jlebon]

It'd be nice to have, yeah. We could probably just add a workaround for it in the post-processing script. Though hopefully that'd be a temporary thing.

One thing I'll mention is that the sssd issue mentions that an empty sssd.conf works fine, but that wasn't the case for me. I'd get:

sssd[1559]: SSSD couldn't load the configuration database [5]: Input/output error.

My workaround for now consists of:

cat > /etc/sssd/sssd.conf << EOF
[sssd]
services = nss
config_file_version = 2
EOF
chmod 0600 /etc/sssd/sssd.conf

which I think is as "no-op" as one can get?

[jhrozek]

On 2 May 2018, at 15:15, Jonathan Lebon ***@***.***> wrote: It'd be nice to have, yeah. We could probably just add a workaround for it in the post-processing script. Though hopefully that'd be a temporary thing. One thing I'll mention is that the sssd issue mentions that an empty sssd.conf works fine, but that wasn't the case for me. I'd get: sssd[1559]: SSSD couldn't load the configuration database [5]: Input/output error.

This sounds strange and I can’t reproduce this problem locally. Would you mind opening an issue on sssd pagure instance and include the version and exactly how you reproduce the issue? Is this with the snippet or without?

…

My workaround for now consists of: cat > /etc/sssd/sssd.conf << EOF [sssd] services = nss config_file_version = 2 EOF chmod 0600 /etc/sssd/sssd.conf which I think is as "no-op" as one can get? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[pbrezina]

I'm closing this issue since we found a way that suites both sides. Please, re-open if you feel otherwise.

[nullr0ute]

Could you document here what that way is so other people that might run into it can find out easily

[pbrezina]

Atomic chose to use SSSD's new local user support feature which can also provide users from alternative passwd files, which is precisely what altfiles does. Example of such configuration can be seen at https://github.com/pbrezina/authselect/issues/48#issuecomment-384973785

[cgwalters]

Just to note here, one thing that wasn't obvious to me at first is that a major problem is a lot of kickstarts we have cargo cult around authconfig --enableshadow --passalgo=sha512 which is necessary for RHEL7, but AIUI shouldn't be needed anymore. See e.g. https://pagure.io/teamsilverblue/issue/34

So anyone hitting this via kickstart should simply delete that line.