Stephen Gallagher <sgallagh(a)redhat.com> wrote on 2014/09/25 17:36:08:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/25/2014 11:01 AM, John Hodrien wrote:
> On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
>
>> Yes, it is "my" job, not sssd's. Currently sssd dictate that no
>> system ever should be allowed to login as root, no matter what.
>
> SSSD dictates that no system should be allowed to login as root
> via SSSD, and that's not quite the same. You're a corner case
> where you're working against standard practice, but I can see why
> you think it should be possible to configure SSSD to allow it,
> given that you can strip away these sanity checks from PAM.
>
Just to reiterate what I said elsewhere in this thread (without CCing
Joakim, sorry):
There are two reasons why SSSD refuses to handle root:
1) If SSSD was to crash, only root is capable of restarting it,
debugging it or otherwise fixing the problem. So if you hit a bug and
SSSD was the mechanism you used to log in as root, it cannot be fixed
short of a reboot (and if the bug happens on every run because there
was a regression in an update, your system is hosed.)
2) Without root in /etc/passwd and /etc/shadow, it's impossible to
boot into single-user mode to fix any issues with the early boot
process.
Don't quite follow here. I do have a local root user in passwd/shadow with
a
local pw as required by any UNIX I know. I also have a AD root account.
When logging in as root PAM first tries the local root account and
if that fails SSSD is asked to authenticate.
So if I use the local root pw PAM logs me in without SSSD involment,
but if I use the domain root user pw, SSSD should log me in.
These are the reasons that SSSD doesn't handle the root user. It's not
a matter of a default, it's a matter of protecting users from an
inevitable catastrophe. No matter how hard we try, bugs will always
creep in. If you can't get in to fix them, then a bug becomes a
disaster.
I cannot see how my case above can cause a catastrophe such as 1)
Jocke