This change confuses me, and I'm still not sure how to vote for this yet...

-1 for right now.

I don't quite understand the rationale for this and I vehemently disagree with configuration in hidden directories.

Please note that these files are not configuration, it is used by authselect to determine if there were any user changes (without calling authselect) to the /etc/nsswitch and /etc/pam.d/*-auth files. The reason why we need to move them is to make authselect functional on CoreOS and other ostree system since /var is not writable when the image builds.

If this change is not accepted, we have two choices:
a) revert https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory therefore pam won't require authselect and authselect won't get pulled in CoreOS
b) drop this functionality and for example rely on the presence of /etc/authselect/authselect.conf - if it is there then any authselect call will override the configuration, if it is not then authselect will require --force argument to do so. I think it make sense, wanted to propose it for Fedora 37. This will however require a new change page.

Please note that these files are not configuration, it is used by authselect to determine if there were any user changes (without calling authselect) to the /etc/nsswitch and /etc/pam.d/*-auth files.

So you only want to keep track of user changes in /etc?

Why not keep a copy of the "original" files in /usr somewhere, and compare sha256sums or something to see if there are modifications from the default? That would not require adding even more state files, but maybe I am thinking too simple here.

I'm still not sure why we don't just leverage the libeconf functionality in PAM and move mandatory functional configuration to /usr for PAM...

Please note that these files are not configuration, it is used by authselect to determine if there were any user changes (without calling authselect) to the /etc/nsswitch and /etc/pam.d/*-auth files.

So you only want to keep track of user changes in /etc?

Why not keep a copy of the "original" files in /usr somewhere, and compare sha256sums or something to see if there are modifications from the default? That would not require adding even more state files, but maybe I am thinking too simple here.

The problem is that /usr is read-only for users, /var is read-only on when ostree image is being built and this causes problem to authselect since it needs to function on both sides and this data is changed with each authselect call.

Authselect currently stores this data in /var/lib/authselect, which is imho correct place for such kind of data. However, with the change we did in F36 here we essentially removed static configuration from the pam and glibc package and the default configuration is now generated by authselect in %post.

At this moment, I don't see any other solution then either move the files to /etc which is writable in either case, or drop this functionality, which I think is feasible, but definitely requires another change page to communicate this.

I'm still not sure why we don't just leverage the libeconf functionality in PAM and move mandatory functional configuration to /usr for PAM...

It doesn't solve the problem at hand. /usr is not writable on ostree for users so they would not be able to use authselect to setup their configuration (if authselect writes to /usr/lib/pam.d) or nothing changes (if authselect writes to /etc/pam.d).

@pbrezina

OK, so I think I understand what you're saying now. Essentially, the content in the .state directory is "The last thing authconfig wrote out" as a reference. It's not static, because it's entirely dependent upon the user's input. It's meant to be there to identify changes between what authconfig originally wrote and the user edited.

With that in mind, I agree that this content absolutely belongs in /var. I think the core of the problem then is the read-only nature of /var in ostree and the fact that you are attempting to write the default configuration in %post.

Instead of %post, you should follow the guidelines for First-time Service Setup. This is compatible with the ostree model, since the data isn't written into /var until the first boot, rather than at the image-creation time.

Correction: you should slightly adapt those guidelines, since you won't be tying it to a running service. So you'd want a standalone oneshot service unit and a preset to enable it.

Yes, I think we are on the same page now.

That, however, would not work on containers where systemd is not available, but pam and nsswitch are. So you want to get the pam and nsswitch configuration from authselect but without pulling in systemd and requiring it to run. Additionally, there are other packages (like fprintd and nss-mdns) that call authselect from %post to auto-enable their modules so that would not work as well.

Authselect is a bit special, since it is not a standalone service and integrates multiple low level parts.

Authselect is trying to be very defensive against manual changes to the configuration, but since Fedora 36 tries to move everyone to authselect and it is the recommended way now, I think it is fine to relax this condition. I originally wanted to propose it to Fedora 37 anyway, to really remove the possibility of having a mixed configuration (created by authselect, but modified by user). But it is fine to do it in Fedora 36 as well, maybe it is even better to do this kind of change at once.

I propose:

• if /etc/authselect/authselect.conf exists and is valid then all authselect calls will (over)write the configuration and will not require user's confirmation through --force parameter
• if /etc/authselect/authselect.conf does not exist or is corrupted, then authselect will require --force parameter
• the content of the files is no longer checked, therefore the files under /var/lib/authselect are no longer needed
• those users that don't want to have their configuration managed by authselect can either
  • remove /etc/authselect/authselect.conf,
  • or ideally run authselect opt-out which will remove the configuration file and also move the files from being symlink (like /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf) to regular files
• the result is that users would either use authselect or not, nothing in between

This will make the behavior consistent and functional across all platforms. This was already mentioned in the side discussion about this change and welcomed by Vít.

Also it is similar to what other services (eg NetworkManager, systemd-resolved) do - unless disabled, they don't mind overwriting user's changes to /etc/resolv.conf.

Would it be possible to include this change in Fedora 36? Can I get an exception to go through the standard change process even after proposal submission deadline? Or is a change page not required?

Thank you for considering it.

Also please note, that I have required code changes ready, so I can meet code completion testable deadline.

Would that allow you to get rid of the hidden directory thing you mention in this change?

Would that allow you to get rid of the hidden directory thing you mention in this change?

Yes.

Then sure, if you can make those changes to the proposal, then I'm +1

(admittedly, I'm still confused, but my main objections kind of go away...)

Should I just rename and update the change page or create a new one and go through the whole process?

Please update the existing one.

I updated the change page. Should I also move it to a new location or keep it on the same url?

You can do whatever you like, talk to @bcotton about it to make sure whatever you do is handled properly.

Thanks, moved to https://fedoraproject.org/wiki/Changes/Authselect_Require_explicit_opt-out

Given the changes, we'll restart the approval voting period.

+1 from me, and thank you Pavel for your hard work here!

+1

+1, thank you for the work you put into this.

+1 here now. Many thanks for being flexable and taking feedback. :)

+1

+1

Approved in today's meeting.

APPROVED(+7,0,-0)

Oh, the meeting minutes were not sent out from the last meeting, sorry for closing this.

Thank you. When will be the tracker bug for this change created? I'd like to submit the build.

Thank you. When will be the tracker bug for this change created? I'd like to submit the build.

I'll do that now. Since the voting clock was restarted, the 7-day period runs out today. I missed that it was given approval in the meeting.

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2XAAO4AXKGLTIKRJZCXTA7JTI2EUFDGY/