User accounts not working, made bad choices

Ask Fedora
1

Ok, I’ve done something that has disabled my system, and has me baffled. Hoping for a little help.

I tried to figure out why a flatpak wasn’t updating correctly, and got impatient. I found out what resetting is in rpm-ostree, by losing all of my virtualization packages that I had installed. But I reinstalled them, and all of my VMs were there, I was OK.

But then, I made a mistake. I figured I’d finally put my account in the libvirt group, so I wouldn’t have to enter my password when I started it. No problem, I did a usermod -G libvirt murph, shut down, and left for a tech meeting. All good.

Not good. When I got there, I logged in, and tried to start virt-manager, but it asked for a password. Now, my user password would not start it. it looked like it wanted a root (or admin, I don’t recall exactly) password. I doubled down to fix it. I followed some instructions, booted into single user mode, and set a password for root.

Bad move. Now, I can’t log in with my user password, or root password. I looked up directions for resetting under silverblue, bazzite. Followed them, nothing works. I’m stuck

I’ve backed up all my data, in case recovery goes badly.

Does anyone out there have any ideas on how to repair this? I

I posted this in the Fedora Matrix group, and I have already tried this to no avail:
Troubleshooting - Fedora Docs

Thanks,
–murph

2

Normally, on traditional desktops, this would be solved by autorelabeling the filesystem.

While I am using both Workstation and Silverblue, I haven’t tried it on Silverblue yet (at least not until now). I assume there are some differences, given the nature atomic desktops. Nevertheless, I’ve just tried autorelabeling on a Silverblue VM, and it seems to be working. This is how it can be done: when the GRUB menu appears, edit the desired entry (OSTree deployment), add the following at the end of the line staring with linux:

autorelabel=1

Press Ctrl+x to boot with the modified GRUB entry. Reaching GDM should take longer than usual, given the additional process of autorelabeling.

I haven’t tested the impact extensively, so go with caution.

3

Alternatively, If you would like to avoid relabeling the whole filesystem, and restore SELinux permissions on /etc/ only, given that probably /etc/shadow and /etc/gshadow are the affected files, you could go like this:

  • Edit the GRUB entry, by adding enforcing=0 to the end of the line starting with linux.
  • Boot with the modified command. This will let you log in, since SELinux was temporarily set to permissive mode.
  • Run the following in a terminal to restore SELinux permissions on the contents of /etc/:
sudo restorecon -vrF /etc/
  • Reboot, and make sure SELinux is set to enforcing, with sestatus.
4

You probably already know this, but the command should have been

usermod -G libvirt,wheel murph

so you would keep the wheel group as one of the groups for your userid.

I don’t know how to fix this in silverblue, It is so much different from the normal Workspace system when it comes to the file systems and how they are mounted.

Perhaps your install USB stick has a recover option. As far as I can see the silverblue install image does have a resque option.

1 Like
5

That should have been usermod -a -G libvirt murph to add the libvirt group to the already existing groups for your user.

from the usermod man page

OPTIONS
       The options which apply to the usermod command are:

       -a, --append
           Add the user to the supplementary group(s). Use only with the -G option.
1 Like
6

Yes I guess the -G is overriding the default groups and removing you from wheel.

That… is not good.

Is the systeam easily recoverable? Like live media, chroot and stuff

7

Usermod has been that way for many years.

       -G, --groups GROUP1[,GROUP2,...[,GROUPN]]]
           A list of supplementary groups which the user is also a member of. Each group is separated from the next by a comma, with no
           intervening whitespace. The groups must exist.

           If the user is currently a member of a group which is not listed, the user will be removed from the group. This behaviour can be
           changed via the -a option, which appends the user to the current supplementary group list.
1 Like
8

So, do you think that using that autorelabel line would be after doing the steps in the included link? I would assume that since it didn’t work, that the changes would have been reverted?

So, do you think it would be:
Reboot into rescue according to the included link: Follow instructions to reset user account, (and maybe also root account, since the user account is still not in the wheel group anymore)

Then, reboot again, using your suggested autorelabel=1 addition to the “linux” line?

Would those be the steps to try, or something else?

Thanks,
–murph

9

Yep, I realize I made a mistake there, but too late.

10

The autorelabeling step should come after performing the steps at the simple bash prompt.

You don’t need to perform those steps again, it’s not that they didn’t work, but rather that those changes affected the security context of /etc/shadow, which leads to what you’re experiencing: password is not accepted. Autorelabeling should fix that.

Once you’re booted into a full environment (graphical or text), you should be able to add your user back to the wheel group.

11

Now that I think about it, there should have been an even easier solution: a nice thing about atomic desktops is that when creating a new deployment, it also saves the current state of the /etc/ folder.

This means that your recent usermod changes shouldn’t have touched the previous deployment. I’m wondering if you did try booting with it?

1 Like
12

You are correct! I thought that /etc was not part of the system state, but I booted into the other, and it worked.

I’ll take a look online on how to get rid of the other one, and/or pin this one until an update.

13

rpm-ostree rollback, run from within the “bootable” deployment will make it the default. Then an upgrade will get rid of the deployment with issues.

14

That was a fantastic idea, I didn’t try it, since I didn’t think that /etc/ would be reverted, I thought that it was saved like the home directories. Good to know, and something to explore in the future.

When that worked, I tried ending the “linux” line with “autorelabel=1” (on the first, non-workign one) and it worked!

I am able to log in now. So I went from nothing to TWO working possibilities.

So, just to get the original working correctly, I guess I could try to boot into single user mode again, use usermod correctly to get myself into all of the proper groups, and then use autorelabel again to get those changes recognized.

Sounds like a plan?

15

It’s harder when you have choices. :slight_smile:

If you want tot forget about the deployment with issues, it’s simple, as described above.

If, on the other hand, you’d like to keep it as the current deployment, then you can just simply boot into it, now that the security contexts have been restored, and make the changes in a standard session logged in with your user. There is no need to boot into single-user mode, you can add your user to the wheel group from within a graphical session, inside the terminal (emulator).

You would need to su (as root), run the necessary usermod command, exit su, test that the user is indeed in the wheel group, then you can disable the root account for additional security (which has been enabled as you followed the linked guide), with sudo passwd -l root.

16

Did autorelabel or rolling back change anything?

This is not an SELinux issue, you removed the user from wheel. And users are not part of the immutable partitions so rolling back doesnt change this.

It now is an SELinux issue, sorry for not reading all. And the /etc backups are useful!

17

Actually it is, as a result of resetting the root password in Rescue Mode. The Quick Docs guide does mention the requirement to autorelabel the filesystem after such action (though a step is missing, as reported here). However, the Silverblue guide for resetting passwords has a different approach, it seems not to be complete in regards to restoring the security contexts either.

The OP managed to log into the deployment with issues after autorelabeling.

1 Like
18

/etc/ is preserved with each deployment, and therefore so is /etc/shadow. You can test that by creating a new user with your last deployment (ostree:0), and you’ll notice it is not available if you boot into the previous deployment (ostree:1).

2 Likes
19

The autorelabel got it so that I could log in again, so -great-. But you are right, I still did not have wheel rights on that account.

The fix was to go back into rescue mode, as root, make the changes to my account, and then on the next boot, select autorelabel again.

So I’m working now, with the exception of the libvirt group, which I tried to do at the same time as wheel, but it didn’t seem to work.

Since I now have my system back to working again, I’m stepping back, taking a breath, and making sure I have everything OK before going back down that road of discovery. Maybe I’ll spin up a silverblue VM, and break THAT instead of my good laptop, figure it out, and then apply to the good machine.

Thanks to all, especially @tqcharm for all the help. I was pretty close, but some of the instructions were incomplete, and the help was invaluable.

1 Like
20

I linked this before, but in case you missed it, there’s an extra step needed to add a user to a system group on Silverblue:

https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/#_unable_to_add_user_to_group

2 Likes