Change: Authselect: Hardcode nss-altfiles in profiles #3663

Closed
opened 2026-07-28 15:47:34 +00:00 by amoloney · 14 comments
Owner

Currently, authselect users can enable nss-altfiles in nsswitch.conf using "with-altfiles" feature. This proposal is to remove the feature and hardcode nss-altfiles support in nsswitch.conf in all shipped profiles, making it required.

Owners, do not implement this work until the FESCo vote has explicitly ended.
When a FESCo member has marked this ticket as APPROVED, you may proceed with the implementation. See the FESCo ticket policy and the Changes policy for more information.
If no decision has been rendered after 7 days from the filing of this ticket and no indication (such as a -1 vote) that this will be taken up at a FESCo meeting, please feel free to ping for a status update.

REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.

Currently, authselect users can enable nss-altfiles in nsswitch.conf using "with-altfiles" feature. This proposal is to remove the feature and hardcode nss-altfiles support in nsswitch.conf in all shipped profiles, making it required. * [Change proposal](https://fedoraproject.org/wiki/Changes/Enable_nss-altfiles_for_all_installations) * [devel post](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SKM5W6V5PVA7KZOKGDNZPIHB3HAGYEOS/) * [Discourse discussion](https://discussion.fedoraproject.org/t/f45-change-proposal-authselect-hardcode-nss-altfiles-in-profiles-self-contained/197236) * Owners: @pbrezina **Owners, do not implement this work until the FESCo vote has explicitly ended.** When a FESCo member has marked this ticket as APPROVED, you may proceed with the implementation. See the [FESCo ticket policy](https://docs.fedoraproject.org/en-US/fesco/#_ticket_policy) and the [Changes policy](https://docs.fedoraproject.org/en-US/program_management/changes_policy/) for more information. If no decision has been rendered after 7 days from the filing of this ticket and no indication (such as a -1 vote) that this will be taken up at a FESCo meeting, please feel free to ping for a status update. **REMINDER**: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the [Fedora Devel](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/) mailing list.
Author
Owner
cc @pbrezina
Owner

The links here are pointing to another change.

The links here are pointing to another change.
Owner

Summary is also incorrect

Summary is also incorrect
Owner

Updated

Updated
Owner

I'm -1. There are no benefits listed for non-Atomic installations in the change request and we know that we have a lot of problems related to nss-altfiles in Atomic ones:

We haven't moved away from using nss-altfiles yet because it requires work to migrate existing systems and things "mostly" work for now and the problems are known (UID/GID drifts, etc.).

But this is really high on my TODO list.

I'm -1. There are no benefits listed for non-Atomic installations in the change request and we know that we have a lot of problems related to nss-altfiles in Atomic ones: - https://forge.fedoraproject.org/atomic-desktops/tracker/issues/108 - https://forge.fedoraproject.org/atomic/tracker/issues/87 We haven't moved away from using nss-altfiles yet because it requires work to migrate existing systems and things "mostly" work for now and the problems are known (UID/GID drifts, etc.). But this is really high on my TODO list.
Owner

High level summary of the issues with nss-altfiles:

Issues specific to building bootable container images:

High level summary of the issues with nss-altfiles: - The user/group manipulation tools do not understand it. If you have a group defined in a file read from nss-altfiles, you need workarounds to add a user to it: https://docs.fedoraproject.org/en-US/atomic-desktops/troubleshooting/#_unable_to_add_user_to_group - The shadow/gshadow tools also do not understand it. If you add a group to the nss-altfile config, it does not get added to gshadow, causing all sorts of issues: https://github.com/bootc-dev/bootc/issues/1179 / https://forge.fedoraproject.org/kde/tracker/issues/684 - Any user/group manipulation/usage will require going through nss otherwise those user/groups are invisible. This notably means that running tools from another rootfs without nss-altfiles enabled may duplicate / mess up the confguration. Issues specific to building bootable container images: - https://bootc.dev/bootc/building/users-and-groups.html#uidgid-drift - Example workaround that is needed: - https://github.com/openshift/os/pull/1918 - https://github.com/coreos/rhel-coreos-config/pull/224 - https://docs.fedoraproject.org/en-US/bootc/building-containers/#_invoking_useradd_as_part_of_a_container_build
Owner

Thanks, that is very helpful context. I wonder if, given the list of known affected tooling whether this should be classified as "system-wide" instead ...

Either way, the -1 vote puts this on the agenda for next week's meeting, so we'll have some chance to discuss this.

Thanks, that is very helpful context. I wonder if, given the list of known affected tooling whether this should be classified as "system-wide" instead ... Either way, the -1 vote puts this on the agenda for next week's meeting, so we'll have some chance to discuss this.

Hi, I'm commenting as the author of the change. I am fine to wait until nss-altfiles requirement is removed from atomic images - that would be the ideal and preferred solution. However, I would like to see a concrete timeline, not promises or wishful thinking since this is on the table for at least since Fedora 27 ~9 years. If I see that this becomes a priority, I am happy to revoke the change.

Hi, I'm commenting as the author of the change. I am fine to wait until nss-altfiles requirement is removed from atomic images - that would be the ideal and preferred solution. However, I would like to see a concrete timeline, not promises or wishful thinking since this is on the table for at least since Fedora 27 ~9 years. If I see that this becomes a priority, I am happy to revoke the change.
Owner
This topic is on the agenda for today's meeting: <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PWMQRM2RQXWIGSQQPX643JE3ADM5Y3AC/>
Owner

I'm -1 on this as well.

I'm -1 on this as well.
Owner

This was discussed during today's meeting. The Change proposal is REJECTED (+6, 0, -0) (meeting log starting at 17:06:48).

!info FESCo would like to see a resolution to this longstanding problem area and encourages the relevant parties (CoreOS, Atomic, bootc initiative, authselect maintainers) to collaborate.

Maybe @nimbinatus can help get things unstuck here as Bootc Initiative lead?

This was discussed during today's meeting. The Change proposal is REJECTED (+6, 0, -0) ([meeting log](https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-08-04/fesco.2026-08-04-17.00.log.html) starting at 17:06:48). !info FESCo would like to see a resolution to this longstanding problem area and encourages the relevant parties (CoreOS, Atomic, bootc initiative, authselect maintainers) to collaborate. Maybe @nimbinatus can help get things unstuck here as Bootc Initiative lead?

👋 Let me get the discussion going in the initiative channel on Matrix, see if I can get a firm timeline for you in the next couple weeks.

👋 Let me get the discussion going in the initiative channel on Matrix, see if I can get a firm timeline for you in the next couple weeks.
Author
Owner

Change rejection now processed.

Change rejection now processed.
Owner

Thanks Aoife!

Thanks Aoife!
Sign in to join this conversation.
No milestone
No project
No assignees
7 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
fesco/tickets#3663
No description provided.