F45 Change Proposal: Authselect: Hardcode nss-altfiles in profiles (self-contained)

Project Discussion Change Proposals
,
1

:link: Authselect: Hardcode nss-altfiles in profiles

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

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.

:link: Owner

:link: Detailed Description

Currently, non-ostree systems (e.g. Fedora Workstation) have nss-altfiles nsswitch.conf module optional in authselect profiles. Users can enable this module by calling “authselect enable-feature with-altfiles” or directly when selecting the profile “authselect select $profile with-altfiles”.

However, the nss-altfiles nsswitch.conf module is required to be enabled on ostree systems (e.g. Fedora Silverblue) and must not be disabled there to make system users available to the system. This is currently handled by authselect in %post scriptlet that modifies the shipped profiles and hardcodes nss-altfiles in them.

This solution, however, makes authselect different on ostree and non-ostree systems. The history also showed that it is quite fragile and easy to break with modifications to the profiles. The intention is to hardcode nss-altfiles on both ostree and non-ostree, making authselect install exactly the same files on both distribution types.

:link: Feedback

None.

:link: Benefit to Fedora

Both ostree and non-ostree Fedora releases will ship exactly the same authselect content.

:link: Scope

  • Proposal owners: Do the work in upstream and release it in Fedora.

  • Other developers: None.

  • Release engineering: None. #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

None. Upgrade path will be handled by authselect.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

1. Check that with-altfiles is no longer available in the profiles 2. Check that “altfiles” is present in generated /etc/nsswitch.conf

:link: User Experience

User’s should not notice the change.

:link: Dependencies

None.

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

The “with-altfiles” feature has been removed from all authselect profiles. The nss-altfiles support is now enabled and can not be disabled.

Last edited by @amoloney 2026-07-20T14:25:45Z

Last edited by @amoloney 2026-07-20T14:25:45Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Reading

The “with-altfiles” feature has been removed from all authselect profiles. The nss-altfiles support is now enabled and can not be disabled.

I have a slight concern about the upgrade path. Specifically, I have

$ authselect current
Profile ID: custom/minimal-altfiles-hosts
Enabled features:
- with-altfiles
- with-mdns4

in my setups, which generates

$ grep altfiles /etc/nsswitch.conf
passwd:     files altfiles systemd
group:      files altfiles systemd
hosts:      files altfiles myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

Will folks like me who use {if "with-altfiles":altfiles } in their custom profiles have to change their profile definitions, or will the with-altfiles still be available, just not needed in the stock profiles?

4

I wouldn’t expect so. This change proposal is just modifying the system profiles under /usr/share/authselect/default right? If you are using a custom profile (under /etc/authselect/custom), that will be unaffected and I don’t see any reason why you would need to revise it.

IIUC, that tag originates from the content of the profile definition itself. If that tag still exists in your custom profile, then you should still be able to select it with the authselect command.

From man authselect-profiles:

CONDITIONAL LINES
Each of these files serves as a template. A template is a plain text file with optional usage of several operators that can be used to provide some optional profile features.

1 Like
5

It depends.

If you have custom profile that symlinks nsswitch.conf (authselect create-profile --symlink-nsswitch) from the shipped profile, the with-altfiles will be gone, altfiles will be hardcoded - the functionality will not change, but the profile will.

If your custom profile provides your own nsswitch.conf, it will stay as is. We will only change the profiles that are shipped with rpm.

The “features” are read from the profiles, they are not defined anywhere in authselect’s code.

1 Like
6

The title describes what happens at the technical level, but the process of publishing a Change Proposal is actually mainly addressed at people who far away from the subject area and care more about the high-level picture. In addition, “hardcode” sounds like a something bad, a hack.

Maybe change the title to something positive, like “Enable nss-altfiles for all installations” ?

7

This is a good tip, thank you. I changed the title and also extended the upgrade path to address Jan’s concerns.

8

It’s a proposal to make “ostree life” simpler by changing what is enabled on rpm installs. So the proposal should at least make it clear what the consequences of this change are for rpm installs, that is which consequences enabling the extra authselect module has or can have.

1 Like
9

I updated the “User Experience” part.

10

In the Atomic group we have plans to move away from nss-atlfiles Making sure you're not a bot!, I am not sure if this will happen for f45 tho.
Tagging @siosm who has more context on this

1 Like
11

AFAIK the plans are there for many many years, ever since the first authselect release reached Fedora. If you could prioritize it and fix it reasonably soon, I can wait and we can drop this change. However, this is not the first time I opened this discussion and I always get “we have plans”, but I miss the action so I would like to get concrete timeline this time :slight_smile:

12

Unless the plan to move away from nss-altfiles is very concrete, I think the current proposal makes sense to do. The changes necessary are relatively small, so it’d make sense to do them, even if at some point in the future we’ll switch to something else. (It’ll also be easier to do the eventual switch from a uniform base.)

13

Thanks, but “should not notice any difference” does not explain the difference. IIUC then the change enables a module which was not enabled before. In terms of security, I’d rather not enable an authentication module unless I use it, even if it is “unconfigured”.

14

It’s a very good point. Does this change increase the attack surface for users with non-readonly /usr/lib directories? There are extra SELinux rules on the /etc/passwd and /etc/group files to make it more difficult for a rogue program to add a user or add a user to a privileged group like wheel. Are the SELinux permissions on /usr/lib equally as strict so that a rogue program could not get around those restrictions by creating or changing the new /usr/lib/passwd and /usr/lib/group files?

15

This change proposal has now been submitted to FESCo with ticket [#3663](Making sure you're not a bot!) for voting.

To find out more, please visit our [Changes Policy](Making sure you're not a bot!) documentation.

16

Strictly speaking, reading additional files does increase the attack surface. But the increase is really minimal. If the attacker has ability to write files under /usr, in any fashion or form, the game is over. They wouldn’t need to use nss-altfiles in further steps, they can already replace arbitrary binaries in the system and do whatever they want.

A second increase in the attack surface is use of an additional module. But nss-altfiles has a good vulnerability history (zero, based on a quick search). This is a really simple module, so I think the security tradeoff is acceptable.

1 Like
17

I posted about the downsides in https://forge.fedoraproject.org/fesco/tickets/issues/3663#issuecomment-1072430.

I don’t see any upside for all package based installations listed in the change request.

I agree this change has been in the planning state for a while as was a not a priority so far. With more and more work going to bootable containers, this surfaced even more problems so it’s likely we’ll do that “soon”.

18

This change has been rejected by FESCo and will not be included in Fedora Linux 45.

To find out more about how our changes policy works, please visit our [docs site](Making sure you're not a bot!).