On Tue, Dec 05, 2017 at 04:14:54PM -0700, Chris Murphy wrote: > On Tue, Dec 5, 2017 at 8:12 AM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > > > > > > On 12/05/2017 07:30 AM, Dominik 'Rathann' Mierzejewski wrote: > >> > >> Then why disable root at all? What if there are no local user accounts, > >> only via a directory service and network is down? This change is clearly > >> not well thought-out. If anything, the redundancy should be reduced on > >> the GNOME side, not anaconda side, as removing stuff from anaconda > >> forces alternative desktop environments to reimplement what GNOME does. > > > > > > We've spend a fair amount of time discussing this change for the past two > > years (including just a few months ago on this list), so I don't think it's > > fair to say it is not well thought-out. Setting up such an environment > > requires significant custom configuration. If you know how to enable a > > directory service for logins, which is not supported by any graphical tools, > > then you surely know how to set a root password using passwd. The default > > Workstation configuration is not relevant in this scenario for that reason > > alone. Also consider that computers in such an environment are probably > > installed via kickstart or netinstall anyway, which are unaffected by this > > change, or at least by a system administrator who can set a root password if > > desired. Not by end users. > > > > The default install in Fedora Workstation should be optimized for a single, > > local, administrator user. Having a separate root account enabled is not > > useful and only leads to confusion. Users do not understand the difference > > between their administrator password and their separate root password. > > Prompting users to set two different passwords at install time is confusing > > and problematic. > > > I agree with all of this. But there is that nitpicky "what if" that > becomes problematic. > > At the moment I'm finding the enforcement of root login in systemd to > be kinda specious because literally anyone trying to compromise a > system they have physical access to, can do this trivially. You can > rd.break=pre-mount and you're dumped to a prompt with root access. You > can likewise do the same with init=/bin/bash. So?? What's the security > advantage of rescue and emergency targets putting up a login at all? To achieve some semblance of security, bios and bootloader have to be protected — this is well understood and documented and some percentage of our users do this. From inside of the system we cannot know if such steps were taken, so we have no choice but to assume that the machine was set up properly and do our part. Please note that there _are_ systems which are suitably protected despite users having physical access: any machine in an university lab, various kiosks, etc. Another scenario where the root password matters is if you have a fully encrypted system. The system might enter emergency mode _after_ the root password has been entered, for example as a result of fsck. Status quo is to require authentication. The way to disabling the root password check would be to consider various installation scenarios and show that there's no additional exposure from disabling it. I'd love for this to be true, because it can be a pain in the ass in the single-user unprotected-laptop case, but as my examples above show, there are nontrivial installation scenarios which would be broken so we cannot do this. OTOH, in the end, the (common) ability to "break" into the system from the bootloader prompt actually means that the password protections are not a big issue: if you have access in this way, this can be used to fix a broken system. Zbyszek > > I do keep root user enabled on my laptop but I think that's > antiquated, I usually use 'sudo -i' rather than literally logging in > as root user. On my Fedora Server, root user is locked (/etc/shadow > passphrase is !). So my only concern is the single user startup > scenario where systemd enforces a root login for reasons that I'm > uncertain about. > > -- > Chris Murphy > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
