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.
Jan