[arch-general] Initramfs fallback render
Hi all, I have always learnt that it was good practice (to use sudo instead of root su and), when we use sudo, to completely disable root login (by disabling his password). However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux? If not, how do you deal with that usually? Thanks in advance for your response! Regards, -- Ismael
On Fri, Nov 15, 2013 at 1:55 AM, Ismael Bouya <ismael.bouya@normalesup.org>wrote:
Hi all,
I have always learnt that it was good practice (to use sudo instead of root su and), when we use sudo, to completely disable root login (by disabling his password).
Well, good practices are sometimes questioned...
However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux?
...because you should only do that when your boot console is secure. The argument is that if anyone has physical access to your computer, they can boot from a LiveCD or USB anyway...
If not, how do you deal with that usually?
Let's go to the point! The pasword is asked by the systemd services "emergency.service" or "rescue.service", that run "/sbin/sulogin". So your easiest solution is to modify these services to use the argument "--force", that according to "man sulogin" will do what you want: For that create the directory "/etc/systemd/system/emergency.service.d" and in it the file "10-nopasswd.conf" with this content: [Service] ExecStart=-/sbin/sulogin --force And the same repacing rescue for emergency. HTH Rodrigo.
(Fri, Nov 15, 2013 at 09:45:15AM +0100) Rodrigo Rivas :
On Fri, Nov 15, 2013 at 1:55 AM, Ismael Bouya <ismael.bouya@normalesup.org>wrote:
However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux?
...because you should only do that when your boot console is secure. The argument is that if anyone has physical access to your computer, they can boot from a LiveCD or USB anyway...
Well, that's how I dealt with my problem, I was lucky that I had one, but...
If not, how do you deal with that usually?
Let's go to the point! The pasword is asked by the systemd services "emergency.service" or "rescue.service", that run "/sbin/sulogin".
So your easiest solution is to modify these services to use the argument "--force", that according to "man sulogin" will do what you want:
For that create the directory "/etc/systemd/system/emergency.service.d" and in it the file "10-nopasswd.conf" with this content:
[Service] ExecStart=-/sbin/sulogin --force
And the same repacing rescue for emergency.
Hum that will accept passwordless login wont it? I was telling of accepting a specific (trusted) user's password instead of root's But at least I know now which direction to look at, I'll test it next time I have physical access to my computer, and report.. Thanks! -- Ismael
On Fri, Nov 15, 2013 at 10:05 AM, Ismael Bouya <ismael.bouya@normalesup.org>wrote:
(Fri, Nov 15, 2013 at 09:45:15AM +0100) Rodrigo Rivas :
On Fri, Nov 15, 2013 at 1:55 AM, Ismael Bouya <ismael.bouya@normalesup.org>wrote:
However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux?
...because you should only do that when your boot console is secure. The argument is that if anyone has physical access to your computer, they can boot from a LiveCD or USB anyway...
Well, that's how I dealt with my problem, I was lucky that I had one, but...
If not, how do you deal with that usually?
Let's go to the point! The pasword is asked by the systemd services "emergency.service" or "rescue.service", that run "/sbin/sulogin".
So your easiest solution is to modify these services to use the argument "--force", that according to "man sulogin" will do what you want:
For that create the directory "/etc/systemd/system/emergency.service.d"
and
in it the file "10-nopasswd.conf" with this content:
[Service] ExecStart=-/sbin/sulogin --force
And the same repacing rescue for emergency.
Hum that will accept passwordless login wont it? I was telling of accepting a specific (trusted) user's password instead of root's
Yes, I thought that was the point. But you want to use the user password... the same as with "sudo", makes sense. You could using "login" instead of "sulogin". Or if you feel brave enough you could even add a link to "getty@tty2.service" or "getty@tty1.service" into "/etc/systemd/system/{rescue,emergency}.target.wants" and see what happens (you may have to manually switch to VT2, though).
But at least I know now which direction to look at, I'll test it next time I have physical access to my computer, and report..
Thanks!
-- Ismael
Best regards! -- Rodrigo
(Fri, Nov 15, 2013 at 02:52:33PM +0100) Rodrigo Rivas :
Yes, I thought that was the point. But you want to use the user password... the same as with "sudo", makes sense. You could using "login" instead of "sulogin". Or if you feel brave enough you could even add a link to "getty@tty2.service" or "getty@tty1.service" into "/etc/systemd/system/{rescue,emergency}.target.wants" and see what happens (you may have to manually switch to VT2, though).
Yes, that's what more or less what I thought about and just did, if I break something up to a point that even this solution doesn't work then maybe I reached a point where it might be a good idea to boot from a key :) Thanks a lot! Mvh, -- Ismael
(Fri, Nov 15, 2013 at 06:00:58PM +0100) Ismael Bouya :
(Fri, Nov 15, 2013 at 02:52:33PM +0100) Rodrigo Rivas :
Yes, I thought that was the point. But you want to use the user password... the same as with "sudo", makes sense. You could using "login" instead of "sulogin". Or if you feel brave enough you could even add a link to "getty@tty2.service" or "getty@tty1.service" into "/etc/systemd/system/{rescue,emergency}.target.wants" and see what happens (you may have to manually switch to VT2, though).
Yes, that's what more or less what I thought about and just did, if I break something up to a point that even this solution doesn't work then maybe I reached a point where it might be a good idea to boot from a key :)
By the way I came to a "dark" point : how does systemd knows that he is started in fallbackmode ? I see no difference in the grub.cfg in the kernel options, and no relevant differences in the initramfs (more modules available and a few lines in ".../modules.devname") Did I miss something or is he doing magic with the name of the initrd file? I found no information of how systemd does that (for the rescue there is a "kernel option" in the man file, but for the emergency there is nothing) -- Ismael
On 11/15/13 at 06:37pm, Ismael Bouya wrote:
By the way I came to a "dark" point : how does systemd knows that he is started in fallbackmode ?
Likely, something is broken with your fallback initramfs. Booting from the fallback should be no different than booting from the normal initramfs. The fallback simply doesn't apply the autodetect hook, so it does not try to exclude unnecessary modules. The fallback is typically useful if you have a disk that you might want to move to another machine with different hardware. It is just not machine specific like th normal one. -- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
On Fri, Nov 15, 2013 at 7:35 PM, Curtis Shimamoto < sugar.and.scruffy@gmail.com> wrote:
On 11/15/13 at 06:37pm, Ismael Bouya wrote:
By the way I came to a "dark" point : how does systemd knows that he is started in fallbackmode ?
Likely, something is broken with your fallback initramfs.
Booting from the fallback should be no different than booting from the normal initramfs. The fallback simply doesn't apply the autodetect hook, so it does not try to exclude unnecessary modules.
The fallback is typically useful if you have a disk that you might want to move to another machine with different hardware. It is just not machine specific like th normal one.
-- Curtis Shimamoto sugar.and.scruffy [at] gmail.com
Maybe the OP is mixing the *fallback* initramfs with the rescue/emergency boot options. They are orthogonal and only the latter ones ask for the root password.
Hum I started to write answers to different emails, but it looks like I messed things between an actual problem (A non-critical hard disk that crashed with no "nofail" option in the fstab) and my tries afterwards to boot in rescue/emergency mode. To answer to Gaëtan, the message that I saw was exactly the one in /usr/lib/systemd/system/{rescue,emergency}.service I know the difference is important but I cannot remember which one it was (most probably it's the one corresponding to what happens when things go bad) Mainly, I made a confusion with what is "usual" in Ubuntu in the grub, that is to have a line for normal booting, and one line for "emergency", that tries as hard as possible to reach a (root) shell even when things go badly. Now I know that I'll have to configure this behavior somehow manually (?) Thanks all for your help! Best regards, -- Ismael
Hi On Thu, Nov 14, 2013 at 4:55 PM, Ismael Bouya <ismael.bouya@normalesup.org> wrote:
Hi all,
I have always learnt that it was good practice (to use sudo instead of root su and), when we use sudo, to completely disable root login (by disabling his password).
In fact disabling root password does not completely prevent a user from logging as root. There are other ways to authenticate e.g. SSH keys (it assumes sshd.config did not disable root login). The "correct" way to disable root completely is to make it expired "usermod --expiredate DATE_IN_PAST root". I tried it on my machine and found that pacman is broken. I believe it uses "su" before running install scripts.
However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux?
If not, how do you deal with that usually?
Thanks in advance for your response!
Regards, -- Ismael
Am 15.11.2013 15:55, schrieb Anatol Pomozov:
The "correct" way to disable root completely is to make it expired "usermod --expiredate DATE_IN_PAST root". I tried it on my machine and found that pacman is broken. I believe it uses "su" before running install scripts.
Nothing about disabling the root account is "correct". If you disable the account, both 'su' and 'sudo' cannot function. You _need_ the root account.
Hi On Fri, Nov 15, 2013 at 7:02 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.11.2013 15:55, schrieb Anatol Pomozov:
The "correct" way to disable root completely is to make it expired "usermod --expiredate DATE_IN_PAST root". I tried it on my machine and found that pacman is broken. I believe it uses "su" before running install scripts.
Nothing about disabling the root account is "correct".
Disabling root account is typical practice on multi-user machines. "sudo" is much better solution as it allows fine-grained control to super-user abilities.
If you disable the account, both 'su' and 'sudo' cannot function. You _need_ the root account.
"--expiredate" differs from "disabling login" that "--expiredate" does not allow to "sudo su" and does not allow any other authentication method (such as ssh keys). Note that "sudo foo" still works even if root account is expired (sudo ignores expiration date of the destination account).
On Fri, 15 Nov 2013 08:33:33 -0800 Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
Hi
On Fri, Nov 15, 2013 at 7:02 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 15.11.2013 15:55, schrieb Anatol Pomozov:
The "correct" way to disable root completely is to make it expired "usermod --expiredate DATE_IN_PAST root". I tried it on my machine and found that pacman is broken. I believe it uses "su" before running install scripts.
I need to check pacman src, but I find this unlikely. If pacman called su(1) wouldn't there be an entry in auth.log? Besides, calling external binaries is a bad practice -- that's what shared libraries are for.
Nothing about disabling the root account is "correct".
Disabling root account is typical practice on multi-user machines. "sudo" is much better solution as it allows fine-grained control to super-user abilities.
I don't know what you mean by "typical", but I am yet to see a rootless supercomputer (as you know, these machines usually have ~100 users logged in at the headnode). The _only_ scenario in which disabling root is useful is when you require audit logs of every administration-related operation, so you use sudo. Everything else sounds like a false sense of security to me... Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
[2013-11-15 01:55:12 +0100] Ismael Bouya:
when we need to boot into "fallback mode", initramfs asks for root password!
What is the exact prompt that seems to be asking for the root password? Wouldn't there be any helpful info/warning/error messages preceding it? That'd clear up some confusion around what part of initramfs (if any) is relevant here... -- Gaetan
participants (7)
-
Anatol Pomozov
-
Curtis Shimamoto
-
Gaetan Bisson
-
Ismael Bouya
-
Leonid Isaev
-
Rodrigo Rivas
-
Thomas Bächler