F21 System Wide Change: The securetty file is empty by default

William Brown william at firstyear.id.au
Tue Apr 15 04:18:51 UTC 2014

On Mon, 2014-04-14 at 23:57 -0400, Simo Sorce wrote:
> On Tue, 2014-04-15 at 08:49 +0700, Michel Alexandre Salim wrote:
> > On 04/14/2014 09:21 PM, Andrew Lutomirski wrote:
> > > On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim
> > > <salimma at fedoraproject.org> wrote:
> > >> Apologies for being late to the discussion as well - just wanted to note
> > >> that I've been running root-password-less configurations for some time
> > >> (by using passwd -l to lock out the root account post-install), and
> > >> later encountered this scenario whereby one of the disks failed fsck and
> > >> I was dropped into a single-user mode login for maintenance, where I was
> > >> prompted for... you get it, the root password.
> > >>
> > >> Resorted to rebooting and disabling fsck from grub, but how to handle
> > >> fsck errors should probably be considered as part of this proposed change.
> > > 
> > > You're not the only one:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1045574
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1087528
> > > 
> > Well, the "fastboot" flag in Grub works as a workaround, my problem is
> > different from those that lost their root password -- I intentionally
> > didn't set one, and expected tasks that in the past required the use of
> > the root password to be doable by the user account nominated to be
> > administrators, whether through %wheel membership or pkcon or other means.
> > 
> > > but I don't think that this is really related to securetty.
> > > 
> > If the use of root account is to be further discouraged, I'm pointing
> > out that workflows that currently require it have to be revised as well.
> I do not think it makes any sense to lock the root account.
> It is perfectly sane to discourage from using root for day to day
> operation and avoid or even disallow to login into the display manager
> with root.
> But disabling it has no useful purpose, you are just going to make
> another account all powerful to compensate, either by giving sudo powers
> or other similar mechanism, what you loose is the ability to properly
> recover a system.
> I am not saying you shouldn't be allowed to do passwd -l, but that
> should not be mandated by the system configuration, purely a choice of
> individual admins.
> Simo.
> -- 
> Simo Sorce * Red Hat, Inc * New York

If you could enter the rescue.target with a username/password instead of
just "enter the password for root" I wouldn't mind a default locked root

Yes, you would have an account that would need at least ALL command
access in sudo. For the rescue.target you could attempt to start sssd
perhaps if you wanted to access network based accounts ...

You also don't lose that ability to recover a system anyway. Because you
can then use physical access and init=/bin/bash if you really got

I guess it's more to discourage the shared root password scenario than

Really, in the same token, should root ssh be disabled by default? 

William Brown <william at firstyear.id.au>

More information about the devel mailing list