Samuel Sieb wrote on Tue, Nov 26, 2019 at 01:38:51AM -0800:
>FWIW this has happened at an association I help at -- they had
VMs with
>no root password set, and users created by puppet some of whom have
>sudo.
>They just expected no root password = no login possible, but it turns
>out 'su' just gave out a root shell with no password entered...
"su" or "sudo"? Your scenario is unclear.
both worked -- that is the point, su should not have worked here.
They basically gave root access to everyone, regardless of sudoer
settings.
>It's easy to fix once I realized that, but it had been that
way for
>quite a while until then; I'd definitely support removing nullok on the
>default install.
I don't think that this proposal would even help with that situation. This
is about user passwords, not root. How were those VMs created?
Whatever the virtualization solution they use to create VMs, it just had
an empty root password.
I haven't checked what is used, I agree it also is a bug in their setup
script (fixed since then), but there are plenty of scenarii where an
empty root password makes sense for VMs/containers e.g. allow logins
from the console by default, so I believe these will continue to do
that.
If you're creating users with sudo access, how can you not expect
to
have root be accessible?
It sure would... I didn't say root user should be locked out to sudoers,
just 'su' shouldn't work.
An alternative might be to go back to securetty settings allowing
console login but not non-interactive su or su over ssh. That does sound
harder to setup/easier to miss, though, and if someone does set a root
password up they would be doubly surprised... I don't think we can tell
it to only look at securetty if the password was empty?
--
Dominique