On Tue, 23 Sep 2014 15:39:19 +0200 Jakub Hrozek <jhro...@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. > 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. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel