Sorry, I'm in mobile and I miss send the draft :S I'm not sure if it's clear: we don't really need so many constraints on anaconda. (active root with pass and regular user) or regular user on wheel group would be enough to elevate privileges on a just installed box remotely
Julen Landa Alustiza <ju...@zokormazo.info> igorleak hau idatzi zuen (2019 mai. 17, or. 16:40): > We are not disabling root access entirely, you can log on local console or > use su after loging with a normal user. > > After installing server without the proposed changes (that could be great, > but not needed) you can log in with the normal user and use su to scalate > privileges and either change sshd_config or add a pubkey on authorized_keys. > > Right now we will need a normal user to be able to access as root after a > remote install, but it does not neccesary need to be part of wheel (I > believe that su is not restricted) > > Just a root user and not a regular one will finish with a box that is not > accesible remotely and that could be a problem > > Stephen Gallagher <sgall...@redhat.com> igorleak hau idatzi zuen (2019 > mai. 17, or. 16:20): > >> On Fri, May 17, 2019 at 8:37 AM Martin Kolman <mkol...@redhat.com> wrote: >> > >> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote: >> > > 3) Force Anaconda to require the creation of a non-root user that is a >> > > member of the `wheel` group, so that this user can be used to SSH in >> > > and administer the system. Essentially, remove the root user creation >> > > spoke as an option from the interactive install. >> > The current policy during ineractive install is, one of (or both) must >> exists: >> > - a root account that is not locked >> > - a user in the wheel group >> > >> > This could be tweaked accordingly (eq. always require at least one user >> in the wheel >> > group regardless of the state of the root account). >> > >> >> I might not have been clear in my original email. My point was mainly >> that I want these problems identified, a solution agreed-upon and >> added to the Change Proposal before it goes to a FESCo vote. I'd be >> inclined to vote -1 without a plan in place to deal with this. This is >> indeed probably the least-intrusive change we can make (and aligns us >> a little closer to how other popular distros are doing things these >> days), and if Anaconda team is willing to commit to doing that work >> here, that would be great. >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
