On Tue, Sep 23, 2014 at 10:03:36AM -0400, Simo Sorce wrote:
On Tue, 23 Sep 2014 15:39:19 +0200
Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On Tue, Sep 23, 2014 at 09:07:06AM -0400, Simo Sorce wrote:
> > > Simo, does the design page reflect the discussion accurately? Can
> > > we start on the implementation?
> >
> > Yes I made a minor edit to the password change clause, should we
> > add a test point about it too ?
> >
> > Simo.
>
> Ah, thank you very much, that much clearer. Yes, I agree we should
> add a test case -- so far I added one that says pretty much what you
> said in the implementation phase. I'm not sure if we need more,
> because normally you're not allowed to chpass as anyone else than
> self and IIRC we explicitly drop password change requests from root.
>
> In another conversation with Dmitri, I proposed two other changes I'd
> like to discuss:
>
> Normally, the list of allowed domains for untrusted users should be
> 'all', which is the current behavirour. However, if the trusted user
> list is set, we should default to 'none' and require that access to
> untrusted domains is set explicitly.
Why ? I do not think we really need to have this, having defaults
change based on other parameters may confuse people.
I would rather just document that you should change the other value in
the man page and documentation.
I'm afraid administrators will not read the docs in full. If the default
is 'allow all' they might just append the domains=foo parameter to the
pam_sss.so line and think that the pam module can only contact a certain
domain. In reality, all untrusted processes would still be able to
access all domains.
Forcing the admin to change the list of domains accessible to untrusted
users would make sure they explicitly spell out the domains..
> The other change is a new [domain] section option, maybe
> "allow_untrusted" that would make it possible to augment the global
> list of domains allowed for untrusted users. While the option doesn't
> have too much use now, it will be very useful when we allow merging
> configs and defining a new domain just by dropping a file.
I would defer this to when we have actual requests for it.
I am not necessarily opposed but it will be confusing. You see a list
of domains (or even 'none') and then you have to (at least
mentally) parse all the code snippets to find out who can do what.
I think domain snippets, in general, should not influence other
services behavior, but just define the domain itself.
OK, we can defer. I will make a note to the ticket that describes
including configuration so that we don't forget.