On Tue, 2012-04-03 at 16:36 +0300, Marko Myllynen 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.
Thanks,
The reason we deferred 1087 is because we feel that if the user has a
preferred shell set on the central server and the same shell is
available on the client machine, then the user should be granted access
to that shell on any machine they log into. We have the 'vetoed_shells'
option in the event that a particular client machine wants to prevent a
user from using a specific shell. Otherwise, if the administrator really
wants to force users to use a particular shell, then the most expedient
solution is to make that change to the central LDAP attribute, thus
percolating it out to all machines trivially.