On Tue, 2012-04-03 at 15:51 +0200, Jan Zelený wrote:
> Hi,
>
> > Ok, I think I understand now, but the manpages need to be MUCH more
> > clear. It sounds like you're adding this option to always override
> > subdomain home directory values. Please clarify the documentation.
> >
> > I still don't see a use for the shells though. The OS already handles
> > this internally by translating a NULL value for the shell into "the
> > system default shell" (usually /bin/sh). This is handled by glibc and
> > isn't our concern.
>
> as with regular domains also with subdomains you might have the
> situation where different domains and users have different values for
> shell (e.g., NULL, /bin/bash, and /bin/tcsh) which in turn will cause
> users logging into a system to have different environment. And the case
> where bash (and other shells) behave differently depending whether
> invoked as /bin/bash or /bin/sh might be something administrators will
> hit especially with subdomains as not all AD domains have UNIX
> attributes enabled.
>
> It would help administrators if SSSD would provide a method to force a
> shell to all users regardless of domain/libc/user configuration but
> unfortunately the RFE requesting this functionality has been deferred
> (#1087). Even though you could state that the shell users will get is
> not of your concern, it is much of a concern for system administrators
> and the subdomain_shell option would seem to be helpful with that regard.
I think a combination of allowed_shells and shell_fallback might be also
helpful in this case. It's not exactly correct solution but it's a solution.
Anyway, the reason why I would like to keep this is the possibility to set
default shell per domain. But if you think that this won't be useful, I can
simply delete it.
Let's pull it out of the current patches and consider it more fully
under the umbrella of ticket 1087, which I just pulled back into
NEEDS_TRIAGE. Sound reasonable?