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?
Yes, let's discuss it on the next meeting.
Thanks
Jan