-----BEGIN PGP SIGNED MESSAGE-----
On 09/25/2014 10:01 AM, John Hodrien wrote:
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
>> is, which is why ssh provides the option:
>> AllowRoot without-password
> Why would I want to enable that?
Because it's more secure than the default of allowing root logins
with password remotely. But forget it, it's not entirely ontopic,
as I'd partially misread what you'd said.
> That is a choice I got in PAM, sssd offers no choice.
> Still, I don't see how the above somehow documents sssd's "no
> root login whatsoever" policy. The docs actually hints the
> opposite: filter_users, filter_groups (string) Exclude certain
> users from being fetched from the sss NSS database. This is
> particularly useful for system accounts. This option can also be
> set per-domain or include fully-qualified names to filter only
> users from the particular domain. Default: root
> This make me think I only have to add an empty filter_users to
> allow root
Sure, the documentation encouragages you to think you could disable
it, and if that's not the case, it's a flaw in the documentation.
Maybe you've got a point that sssd should allow this unusual
SSSD is designed to protect you from yourself. First of all, let's be
clear: SSSD is a daemon and despite our best efforts, a daemon can
fail. If you cannot log in as root using only the /etc/passwd and
/etc/shadow files, it is *impossible* to restart SSSD or get your
Without root in /etc/passwd and /etc/shadow, you also cannot start
your system in single-user mode to deal with critical system failures,
because SSSD would not have been started.
Because of those two *absolutely critical* situations, we expressly
designed SSSD to ignore requests for UID 0. This fundamental decision
is too ingrained to change at this point because it would require a
major rewrite of nearly the entire code.
I have no regrets about this and no: we should not allow this unusual
setup. The only thing that can possibly come out of this is tragedy.
If you want a remote "root" password, the much saner approach would be
to create a central sudo rule allowing a user (or group of users)
privilege to execute 'sudo su -' on all machines. Then you can simply
log in as that user and trivially *become* root, without leaving all
of your machines in a state that will inevitably lead to breakage.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----