Mixing
SELinux reset root password
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Disclaimer: This question is not to solve the problem of changing root password while SELinux is active because there are a lot of guides to solve that already. This is more of how SELinux does that internally.
I'm a recent user of SELinux but lately I've been more in touch with it. There was a moment when someone asked me how I could reset root password in case of forgetting it.
So I booted my CentOS, edited grub entry to something like
....
linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash
...
I ran passwd and afterwards ran sync and forced reboot.
After reboot, logging in with the new password was rejected as well as with the old of course.
Rebooted again and passed the kernel the parameter to disable SELinux (selinux=0). Tried logging in with the new password and it worked.
Afterwards I forced a fs auto relabel (via the file .autorelabel) and with SELinux active it was now possible to log in.
My question is: why does happen? Why does relabeling affect log in when there was merely a change of password and not of users or objects?
Thank you for your attention.
TL;DR: Usual root password reset doesn't work in SELinux. Why?
Edit: This was tested on a virtual machine running CentOS7 with KVM as hypervisor.
redhat selinux
asked 1 hour ago
Jorge Heleno
607
add a comment |Â
up vote
2
down vote
favorite
Disclaimer: This question is not to solve the problem of changing root password while SELinux is active because there are a lot of guides to solve that already. This is more of how SELinux does that internally.
I'm a recent user of SELinux but lately I've been more in touch with it. There was a moment when someone asked me how I could reset root password in case of forgetting it.
So I booted my CentOS, edited grub entry to something like
....
linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash
...
I ran passwd and afterwards ran sync and forced reboot.
After reboot, logging in with the new password was rejected as well as with the old of course.
Rebooted again and passed the kernel the parameter to disable SELinux (selinux=0). Tried logging in with the new password and it worked.
Afterwards I forced a fs auto relabel (via the file .autorelabel) and with SELinux active it was now possible to log in.
My question is: why does happen? Why does relabeling affect log in when there was merely a change of password and not of users or objects?
Thank you for your attention.
TL;DR: Usual root password reset doesn't work in SELinux. Why?
Edit: This was tested on a virtual machine running CentOS7 with KVM as hypervisor.
redhat selinux
asked 1 hour ago
Jorge Heleno
607
1
Are you sure it doesn't work? Try it again. It probably will work fine. I suspect that you simply had wrong file contexts on some files, causing all logins to fail. Thus the autorelabel was what really fixed the problem.
– Michael Hampton♦
1 hour ago
@MichaelHampton I just retraced all my steps doing it again and couldn't log in again with SELinux active. After disabling it I could log in without a problem. Correct me if I'm wrong but changing a password shouldn't change file contexts right?
– Jorge Heleno
1 hour ago
1
No it shouldn't. You seem to have discovered something strange and unexpected.
– Michael Hampton♦
1 hour ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Disclaimer: This question is not to solve the problem of changing root password while SELinux is active because there are a lot of guides to solve that already. This is more of how SELinux does that internally.
I'm a recent user of SELinux but lately I've been more in touch with it. There was a moment when someone asked me how I could reset root password in case of forgetting it.
So I booted my CentOS, edited grub entry to something like
....
linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash
...
I ran passwd and afterwards ran sync and forced reboot.
After reboot, logging in with the new password was rejected as well as with the old of course.
Rebooted again and passed the kernel the parameter to disable SELinux (selinux=0). Tried logging in with the new password and it worked.
Afterwards I forced a fs auto relabel (via the file .autorelabel) and with SELinux active it was now possible to log in.
My question is: why does happen? Why does relabeling affect log in when there was merely a change of password and not of users or objects?
Thank you for your attention.
TL;DR: Usual root password reset doesn't work in SELinux. Why?
Edit: This was tested on a virtual machine running CentOS7 with KVM as hypervisor.
redhat selinux
asked 1 hour ago
Jorge Heleno
607
Disclaimer: This question is not to solve the problem of changing root password while SELinux is active because there are a lot of guides to solve that already. This is more of how SELinux does that internally.
I'm a recent user of SELinux but lately I've been more in touch with it. There was a moment when someone asked me how I could reset root password in case of forgetting it.
So I booted my CentOS, edited grub entry to something like
....
linux16 <kernel_location> root=/dev/mapper/centos-root rw init=/bin/bash
...
I ran passwd and afterwards ran sync and forced reboot.
After reboot, logging in with the new password was rejected as well as with the old of course.
Rebooted again and passed the kernel the parameter to disable SELinux (selinux=0). Tried logging in with the new password and it worked.
Afterwards I forced a fs auto relabel (via the file .autorelabel) and with SELinux active it was now possible to log in.
My question is: why does happen? Why does relabeling affect log in when there was merely a change of password and not of users or objects?
Thank you for your attention.
TL;DR: Usual root password reset doesn't work in SELinux. Why?
Edit: This was tested on a virtual machine running CentOS7 with KVM as hypervisor.
redhat selinux
redhat selinux
asked 1 hour ago
Jorge Heleno
607
asked 1 hour ago
Jorge Heleno
607
edited 1 hour ago
asked 1 hour ago
Jorge Heleno
607
asked 1 hour ago
Jorge Heleno
607
asked 1 hour ago
Jorge Heleno
607
607
1
Are you sure it doesn't work? Try it again. It probably will work fine. I suspect that you simply had wrong file contexts on some files, causing all logins to fail. Thus the autorelabel was what really fixed the problem.
– Michael Hampton♦
1 hour ago
@MichaelHampton I just retraced all my steps doing it again and couldn't log in again with SELinux active. After disabling it I could log in without a problem. Correct me if I'm wrong but changing a password shouldn't change file contexts right?
– Jorge Heleno
1 hour ago
1
No it shouldn't. You seem to have discovered something strange and unexpected.
– Michael Hampton♦
1 hour ago
add a comment |Â
1
Are you sure it doesn't work? Try it again. It probably will work fine. I suspect that you simply had wrong file contexts on some files, causing all logins to fail. Thus the autorelabel was what really fixed the problem.
– Michael Hampton♦
1 hour ago
@MichaelHampton I just retraced all my steps doing it again and couldn't log in again with SELinux active. After disabling it I could log in without a problem. Correct me if I'm wrong but changing a password shouldn't change file contexts right?
– Jorge Heleno
1 hour ago
1
No it shouldn't. You seem to have discovered something strange and unexpected.
– Michael Hampton♦
1 hour ago
1
1
Are you sure it doesn't work? Try it again. It probably will work fine. I suspect that you simply had wrong file contexts on some files, causing all logins to fail. Thus the autorelabel was what really fixed the problem.
– Michael Hampton♦
1 hour ago
Are you sure it doesn't work? Try it again. It probably will work fine. I suspect that you simply had wrong file contexts on some files, causing all logins to fail. Thus the autorelabel was what really fixed the problem.
– Michael Hampton♦
1 hour ago
@MichaelHampton I just retraced all my steps doing it again and couldn't log in again with SELinux active. After disabling it I could log in without a problem. Correct me if I'm wrong but changing a password shouldn't change file contexts right?
– Jorge Heleno
1 hour ago
@MichaelHampton I just retraced all my steps doing it again and couldn't log in again with SELinux active. After disabling it I could log in without a problem. Correct me if I'm wrong but changing a password shouldn't change file contexts right?
– Jorge Heleno
1 hour ago
1
1
No it shouldn't. You seem to have discovered something strange and unexpected.
– Michael Hampton♦
1 hour ago
No it shouldn't. You seem to have discovered something strange and unexpected.
– Michael Hampton♦
1 hour ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
I was able to duplicate this issue in a freshly installed CentOS 7.5 system.
Here is what is happening:
When you boot with init=/bin/bash there are two issues you may run into:
- The root filesystem may be mounted readonly. In this case
passwdwill complain of anAuthentication token manipulation error. - The SELinux policy may not be loaded. In this case
passwdwill appear to succeed, but nothing will happen, and you will have the problem described in the original question above.
To change the root password on RHEL/CentOS 7, you therefore need to follow this process:
- Add
init=/bin/bashto the end of the kernel command line in grub, as you previously did. - At the bash prompt, load the SELinux policy with
/usr/sbin/load_policy -i. - Mount the root filesystem read-write with
mount -o remount,rw /. - Now change the password, and it will succeed.
passwd root - Remount the filesystem readonly to commit changes and have a clean filesystem on next boot with
mount -o remount,ro /. - Exit the shell or restart the system with
exec /sbin/init 6.
Now you can log in with the changed root password.
A longer explanation of this procedure is available from Red Hat (subscription required).
answered 1 hour ago
Michael Hampton♦
158k26293596
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
1
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you runinit=/bin/bash.
– Michael Hampton♦
46 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
I was able to duplicate this issue in a freshly installed CentOS 7.5 system.
Here is what is happening:
When you boot with init=/bin/bash there are two issues you may run into:
- The root filesystem may be mounted readonly. In this case
passwdwill complain of anAuthentication token manipulation error. - The SELinux policy may not be loaded. In this case
passwdwill appear to succeed, but nothing will happen, and you will have the problem described in the original question above.
To change the root password on RHEL/CentOS 7, you therefore need to follow this process:
- Add
init=/bin/bashto the end of the kernel command line in grub, as you previously did. - At the bash prompt, load the SELinux policy with
/usr/sbin/load_policy -i. - Mount the root filesystem read-write with
mount -o remount,rw /. - Now change the password, and it will succeed.
passwd root - Remount the filesystem readonly to commit changes and have a clean filesystem on next boot with
mount -o remount,ro /. - Exit the shell or restart the system with
exec /sbin/init 6.
Now you can log in with the changed root password.
A longer explanation of this procedure is available from Red Hat (subscription required).
answered 1 hour ago
Michael Hampton♦
158k26293596
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
1
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you runinit=/bin/bash.
– Michael Hampton♦
46 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
add a comment |Â
up vote
4
down vote
accepted
I was able to duplicate this issue in a freshly installed CentOS 7.5 system.
Here is what is happening:
When you boot with init=/bin/bash there are two issues you may run into:
- The root filesystem may be mounted readonly. In this case
passwdwill complain of anAuthentication token manipulation error. - The SELinux policy may not be loaded. In this case
passwdwill appear to succeed, but nothing will happen, and you will have the problem described in the original question above.
To change the root password on RHEL/CentOS 7, you therefore need to follow this process:
- Add
init=/bin/bashto the end of the kernel command line in grub, as you previously did. - At the bash prompt, load the SELinux policy with
/usr/sbin/load_policy -i. - Mount the root filesystem read-write with
mount -o remount,rw /. - Now change the password, and it will succeed.
passwd root - Remount the filesystem readonly to commit changes and have a clean filesystem on next boot with
mount -o remount,ro /. - Exit the shell or restart the system with
exec /sbin/init 6.
Now you can log in with the changed root password.
A longer explanation of this procedure is available from Red Hat (subscription required).
answered 1 hour ago
Michael Hampton♦
158k26293596
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
1
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you runinit=/bin/bash.
– Michael Hampton♦
46 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
I was able to duplicate this issue in a freshly installed CentOS 7.5 system.
Here is what is happening:
When you boot with init=/bin/bash there are two issues you may run into:
- The root filesystem may be mounted readonly. In this case
passwdwill complain of anAuthentication token manipulation error. - The SELinux policy may not be loaded. In this case
passwdwill appear to succeed, but nothing will happen, and you will have the problem described in the original question above.
To change the root password on RHEL/CentOS 7, you therefore need to follow this process:
- Add
init=/bin/bashto the end of the kernel command line in grub, as you previously did. - At the bash prompt, load the SELinux policy with
/usr/sbin/load_policy -i. - Mount the root filesystem read-write with
mount -o remount,rw /. - Now change the password, and it will succeed.
passwd root - Remount the filesystem readonly to commit changes and have a clean filesystem on next boot with
mount -o remount,ro /. - Exit the shell or restart the system with
exec /sbin/init 6.
Now you can log in with the changed root password.
A longer explanation of this procedure is available from Red Hat (subscription required).
answered 1 hour ago
Michael Hampton♦
158k26293596
I was able to duplicate this issue in a freshly installed CentOS 7.5 system.
Here is what is happening:
When you boot with init=/bin/bash there are two issues you may run into:
- The root filesystem may be mounted readonly. In this case
passwdwill complain of anAuthentication token manipulation error. - The SELinux policy may not be loaded. In this case
passwdwill appear to succeed, but nothing will happen, and you will have the problem described in the original question above.
To change the root password on RHEL/CentOS 7, you therefore need to follow this process:
- Add
init=/bin/bashto the end of the kernel command line in grub, as you previously did. - At the bash prompt, load the SELinux policy with
/usr/sbin/load_policy -i. - Mount the root filesystem read-write with
mount -o remount,rw /. - Now change the password, and it will succeed.
passwd root - Remount the filesystem readonly to commit changes and have a clean filesystem on next boot with
mount -o remount,ro /. - Exit the shell or restart the system with
exec /sbin/init 6.
Now you can log in with the changed root password.
A longer explanation of this procedure is available from Red Hat (subscription required).
answered 1 hour ago
Michael Hampton♦
158k26293596
answered 1 hour ago
Michael Hampton♦
158k26293596
answered 1 hour ago
Michael Hampton♦
158k26293596
answered 1 hour ago
Michael Hampton♦
158k26293596
158k26293596
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
1
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you runinit=/bin/bash.
– Michael Hampton♦
46 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
add a comment |Â
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
1
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you runinit=/bin/bash.
– Michael Hampton♦
46 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
The problem was on the policies which weren't loaded. Why don't they get loaded? SELinux should operate at kernel level so init system shouldn't be required.
– Jorge Heleno
52 mins ago
1
1
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you run
init=/bin/bash.– Michael Hampton♦
46 mins ago
@JorgeHeleno SELinux is indeed on or off by default when the kernel starts, but the userland is responsible for deciding which policies are loaded. The kernel could not decide this, because some installations may want different policies (e.g. targeted, strict, mls). This happens early in the boot process, but you bypass that when you run
init=/bin/bash.– Michael Hampton♦
46 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
Excellent explanation, thank you very much!
– Jorge Heleno
41 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f936174%2fselinux-reset-root-password%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Are you sure it doesn't work? Try it again. It probably will work fine. I suspect that you simply had wrong file contexts on some files, causing all logins to fail. Thus the autorelabel was what really fixed the problem.
– Michael Hampton♦
1 hour ago
@MichaelHampton I just retraced all my steps doing it again and couldn't log in again with SELinux active. After disabling it I could log in without a problem. Correct me if I'm wrong but changing a password shouldn't change file contexts right?
– Jorge Heleno
1 hour ago
1
No it shouldn't. You seem to have discovered something strange and unexpected.
– Michael Hampton♦
1 hour ago