I creating steps to reset the admin password if forgotten. The final step from the tutorial states:
Next, set the appropriate SELinux context as indicated.
# touch /.autorelabel
The command creates a hidden file called .autorelabel in the root directory. During the reboot, SELinux detects this file and relabels all the files on the system with appropriate SELinux contexts.
If SELinux was not enabled on the server is this step still required? What will autorelabel do if selinux was not enabled?
If in /etc/selinux/config you have it set to disabled then no you don’t need to do this. You would normally only need to do this when selinux is in enforcing mode as far as I am aware. Even if you were running in permissive mode you wouldn’t need to autorelabel either. Mainly because, I believe permissive mode would do the same as what autorelabel would do by running restorecon.
Effectively, with selinux disabled, if you ever decided to enable selinux again, you would either have to do:
Change from disabled to enforcing, and then touch ./autorelabel.
Change from disabled to permissive and reboot the system, and then later change it to enforcing and reboot.
Point 1 effectively saves you an additional reboot. I’m sure someone will correct me if I’m wrong
If, for example, you rescue your system by editing grub, and adding systemd.unit=rescue.target because you forgot or need to reset user passwords (or even root password), the selinux contexts on the files will be lost. This is why you need to reset the contexts by using autorelabel.
Also, the same is required if you disable selinux and then use your system for a certain amount of time, since none of the contexts will be applied to the files. Then if you suddenly enable selinux again into enforcing mode, chances are it won’t boot or certain services will fail. Thus, autorelabel will fix everything and on the next reboot all will be working fine again with selinux enabled.
OK, this is making sense now. I was thinking of selinux in the context of a data partition, but rescue involves the boot and o/s partitions, and you’re not logged in at that point, so you need autorelabel to do it for you.
I’ve never done disaster recovery this way, I usually re-install the o/s and tell it to re-mount the /home and /data partitions (which are on separate drives, and retain all their permissions, attribs and selinux)
I guess it depends on the scale of the problem. If just needing to regain access to your system because the root password is unknown, and no other login has privileges, then a quick reboot into rescue is far quicker than a reinstall of the operating system. Especially if we also take into consideration that any package/application that requires to be reconfigured again to getting it working like it was before reinstall. Sure, if there is a backup you can also restore these, but it’s also far longer and time-consuming doing it that way, than for example utilising rescue mode.
But again, it depends on how trashed the system is and how much time it’s going to take to recover vs restoring/reinstalling. Both are viable options, but I’d much prefer the rescue method or emergency boot to get a system running quickly than losing an hour or more reinstalling and restoring the server to a working state.
I admit in the beginning when I had very little Linux knowledge and my system broke, then I would just reinstall it.
Config management systems can streamline that somewhat. They essentially act as backup of config that is easy to “deploy” (while we “restore” from regular backup). Something like that is very good to have.
Indeed. A nice combo could be to rescue just enough to get system up and then redeploy (in background) the managed config.
A typical way to reset the lost password is to remove it from /etc/passwd.
Modifying it out of context modifies the context, and this needs to be reset through relabeling.
As for doing an autorelabel instead of a targeted one? I suspect it is recommended because it is super easy to explain. The extra relabeling will not hurt and it will possibly catch other files that have been modified over time and possibly prevent future errors, in the case where the context was modified and just needs to be reset, or possibly cause them to occur now instead of the future, in the case of files legitimately added but not properly labeled.
This is not quite disaster recovery level here. Just breaking into a box that is currently inaccessible. Operating with configuration as code is definitely a good way to go. And depending how agile your systems are, how close to immutable, recreating the host and attaching the data may be faster.
There’s arguments to be made in favor of the position that reimplementing the host is more secure.
My environment is not there. Reimplementing a workstation is a half day’s work, easily more if the user has a lot of data onboard.
