On Tue, 2014-04-15 at 13:48 +0930, William Brown wrote: > 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@xxxxxxxxxxxxxxxxx> 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 > account. What user ? In most of my systems there is only root locally, every other user that can authenticate comes from LDAP which is not accessible at rescue time. > 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 ... Why ? sssd may simply be the component at fault here. > 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 > desperate. Sure if you have physical access everything is easier, on a colocated machine that has only serial line access though, that's hardly possible. > I guess it's more to discourage the shared root password scenario than > anything. Why should this be the distribution's task ? That's local policy, not our business, we need to allow such configurations, not mandate them. > Really, in the same token, should root ssh be disabled by default? It may be allowed to login only via publickey/gssapi auth and not password auth I guess. But again this look more like admin policy than something the distribution should enforce by default, IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
