Documentation or Functionality for Resetting Root Password

[nicknamenamenick]

Upstream has documentation on this: https://docs.fedoraproject.org/en-US/quick-docs/reset-root-password/ for Fedora Workstation and other non-atomic Fedora variants.

However, this sparked discussion in Discord that this method may actually not work properly for our images. For those who have a Discord account can view this discussion here, and we regret not making it into its own thread to have it archived on the Answer Overflow.

There are upstream threads surrounding this issue on Fedora Silverblue. There is also this bug report which is now closed but still relevant.

From Fedora Silverblue's Troubleshooting Documentation on the issue:

There are known issues with the read-only filesystem (autorelabel & restorecon) and SELinux (/etc/shadow) with the official documentation.

Does anyone have any experience or other knowledge for this? Whenever this is figured out, we can contribute to upstream documentation as well.

[miabbott]

I think this is generally broken for the Atomic Desktops. I tried following (most of) the root password recovery steps from the generic Fedora docs and they were not successful.

I filed an issue with the Silverblue tracker to see if we can chase this down more broadly - fedora-silverblue/issue-tracker#524

[noelmiller]

So far the process is looking like the following:

1. Edit grub entry and add rd.break enforcing=0 to the end of it
2. mount -o remount rw /sysroot
3. chroot /sysroot
   NOTE: You may need full path: /sysroot/usr/sbin/chroot, one user reported it working without having to provide full path.
4. passwd [your username here]
5. Continue booting your system
6. Run restorecon /etc/shadow as root
7. setenforce 1 to re-enable SELinux

It would be good to confirm upstream whether this is best practice.

[miabbott]

I found that changing my user password via passwd in a normally booted system worked for me without any additional steps. 🤷

[noelmiller]

I found that changing my user password via passwd in a normally booted system worked for me without any additional steps. 🤷

Right, that is if you know your password though. I'm talking about cases where you don't know what your password is.

[miabbott]

3. `chroot /sysroot`

On a freshly installed Silverblue 39 VM, I'm getting chroot: command not found

Might be a different experience on ublue-os derived hosts?

[noelmiller]

On a freshly installed Silverblue 39 VM, I'm getting chroot: command not found

Might be a different experience on ublue-os derived hosts?

That is quite possible. Let me poke around a bit at both and see.

[miabbott]

3. `chroot /sysroot`

On a freshly installed Silverblue 39 VM, I'm getting chroot: command not found

Might be a different experience on ublue-os derived hosts?

Ah...I found it at /sysroot/usr/sbin/chroot

[miabbott]

Ah...I found it at /sysroot/usr/sbin/chroot

When using the instructions above and replacing the chroot with the full path I found, these instructions appear to work successfully on a Silverblue 39 host; both for a normal user password and the root password.

[cgwalters]

The simplest, most generic procedure that works across package and ostree/bootc based Fedora derivatives is:

• Boot with init=/bin/bash on the kernel command line (e.g. edit grub prompt)
• mount -t selinuxfs selinuxfs /sys/fs/selinux
• /sbin/load_policy
• passwd
• sync
• /sbin/reboot -ff

[cgwalters]

(What would be much better to support is systemd.unit=emergency.target but this sadly runs into today is the lack of https://github.com/coreos/fedora-coreos-config/blob/17b7f15f49c00ba1e522f15a72f6df70db01fdcc/overlay.d/05core/usr/lib/systemd/system/emergency.service.d/coreos-sulogin-force.conf#L1 in non-FCOS derivatives.

[noelmiller]

(What would be much better to support is systemd.unit=emergency.target but this sadly runs into today is the lack of https://github.com/coreos/fedora-coreos-config/blob/17b7f15f49c00ba1e522f15a72f6df70db01fdcc/overlay.d/05core/usr/lib/systemd/system/emergency.service.d/coreos-sulogin-force.conf#L1 in non-FCOS derivatives.

To clarify understanding, you are saying that emergency target is not available in projects like Silverblue? Is there an architectural reason?

[cgwalters]

What we really want is a protocol where the boot loader (grub, etc.) can pass down to the OS knowledge of whether it is "unlocked". If the boot loader allows arbitrary edits (e.g. kernel command line) then there's no reason for the OS to prompt you for a root password; it can just drop you into a root shell. That's what SYSTEMD_SULOGIN_FORCE enables.

However, for people making e.g. kiosks, ATMs, etc. or in general a case where a physically present user should not be root, then they need to explicitly lock the boot loader (by e.g. setting a GRUB password) and if they do that, then if we had such a protocol then it'd automatically ensure that things like a fsck failure or anything reaching emergency.target wouldn't be an unexpected privilege escalation.

In the short term I'd definitely advocate for Fedora and derivatives to carry that change by default and tell anyone making kisoks etc. that they need to disable it. We just chose to carry it in FCOS derivatives by default currently.

[noelmiller]

What we really want is a protocol where the boot loader (grub, etc.) can pass down to the OS knowledge of whether it is "unlocked". If the boot loader allows arbitrary edits (e.g. kernel command line) then there's no reason for the OS to prompt you for a root password; it can just drop you into a root shell. That's what SYSTEMD_SULOGIN_FORCE enables.

However, for people making e.g. kiosks, ATMs, etc. or in general a case where a physically present user should not be root, then they need to explicitly lock the boot loader (by e.g. setting a GRUB password) and if they do that, then if we had such a protocol then it'd automatically ensure that things like a fsck failure or anything reaching emergency.target wouldn't be an unexpected privilege escalation.

In the short term I'd definitely advocate for Fedora and derivatives to carry that change by default and tell anyone making kisoks etc. that they need to disable it. We just chose to carry it in FCOS derivatives by default currently.

We may want to consider shipping this by default for our images. Thoughts? @bsherman @castrojo @KyleGospo

[noelmiller]

The simplest, most generic procedure that works across package and ostree/bootc based Fedora derivatives is:

• Boot with init=/bin/bash on the kernel command line (e.g. edit grub prompt)
• mount -t selinuxfs selinuxfs /sys/fs/selinux
• /sbin/load_policy
• passwd
• sync
• /sbin/reboot -ff

@nicknamenamenick This is probably what we should update our documentation with in regards to resetting a user password or root password. The reason this is better is because it mounts selinux and loads the policy so passwd properly labels the /etc/shadow file when making it's changes. It's also less commands.

Another option we could consider is adding a shell script and make it available through just or some other means? Call it ujust _recover-user-password. We don't advocate folks having a password for the root account anyway.

[nicknamenamenick]

Another option we could consider is adding a shell script and make it available through just or some other means? Call it ujust _recover-user-password. We don't advocate folks having a password for the root account anyway.

This is a great idea that I think eventually should be implemented. I will document this on our Discourse documentation first.

[bsherman]

In the short term I'd definitely advocate for Fedora and derivatives to carry that change by default and tell anyone making kisoks etc. that they need to disable it. We just chose to carry it in FCOS derivatives by default currently.

We may want to consider shipping this by default for our images. Thoughts? @bsherman @castrojo @KyleGospo

I support adding the coreos-sulogin-force.conf from https://github.com/coreos/fedora-coreos-config/blob/17b7f15f49c00ba1e522f15a72f6df70db01fdcc/overlay.d/05core/usr/lib/systemd/system/emergency.service.d/coreos-sulogin-force.conf#L1 to our desktop builds, from main on up.

This avoids current hassle for users which doesn't provide any real security benefit.

[noelmiller]

I support adding the coreos-sulogin-force.conf from https://github.com/coreos/fedora-coreos-config/blob/17b7f15f49c00ba1e522f15a72f6df70db01fdcc/overlay.d/05core/usr/lib/systemd/system/emergency.service.d/coreos-sulogin-force.conf#L1 to our desktop builds, from main on up.

This avoids current hassle for users which doesn't provide any real security benefit.

Sounds good, should I make a separate issue in main to implement this? Or do we want more discussion in this thread first?

[bsherman]

Sounds good, should I make a separate issue in main to implement this? Or do we want more discussion in this thread first?

Yep, this current ticket seems to be for documentation, but the change to emergency service implementation should be in a distinct ticket, please.

[travier]

(What would be much better to support is systemd.unit=emergency.target but this sadly runs into today is the lack of coreos/fedora-coreos-config@17b7f15/overlay.d/05core/usr/lib/systemd/system/emergency.service.d/coreos-sulogin-force.conf#L1 in non-FCOS derivatives.

We should probably make this change Fedora wide for all desktops. If folks are interested in driving this through the Fedora process, feel free to reach out to me.

As always, every change that we carry upstream in Fedora, you don't have to maintain here.

[bsherman]

We should probably make this change Fedora wide for all desktops. If folks are interested in driving this through the Fedora process, feel free to reach out to me.

I'm happy to help make this change for all of Fedora.

I will probably soon ask you for guidance.

[noelmiller]

We should probably make this change Fedora wide for all desktops. If folks are interested in driving this through the Fedora process, feel free to reach out to me.

I'm happy to help make this change for all of Fedora.

I will probably soon ask you for guidance.

In that case, we should link the upstream issue in ours once it's created!

[travier]

#470 (comment)