[SSSD] Shell overrides

Stephen Gallagher sgallagh at redhat.com
Fri Jul 29 12:29:12 UTC 2011


On Fri, 2011-07-29 at 13:05 +0100, John Hodrien wrote:
> On Fri, 29 Jul 2011, Jakub Hrozek wrote:
> 
> > On 07/29/2011 12:56 PM, John Hodrien wrote:
> >> Is there a way I can deal with this using the current setup?  I couldn't see a
> >> way.
> >
> > No, not currently. The logic works like this:
> >
> > 1) if the user's shell is on the machine, use it
> > 2) if the user's shell is not installed, but is allowed, map to
> > fallback, usually /bin/sh
> > 3) else /sbin/nologin
> >
> > This feature was meant to cover the case where a user with a fancy shell
> > would try to log into a machine that does not have his shell available.
> 
> Yep.  So am I a strange corner case, or is this something other people would
> be interested in?
> 
> At the very least to aid people migrating from nss_ldap, it'd be good to have
> the nss_ldap equivalent of:
> 
> nss_override_attribute_value loginShell /bin/bash
> 
> For my uses the additional config option actually brings sssd up a notch on
> what I was able to acheive with nss_ldap, but I can understand that our setup
> isn't entirely sane.


Well, it seems to me that you're probably describing a very unusual
corner case. The basic idea we work from in SSSD is that the central
data store should always be authoritative.

Phrased differently, our assumption is that if a user has set their
preferred shell in LDAP, we should do our best to honor that on any
client that supports it, but we should also allow a fallback if their
preferred shell is unavailable. (On nss_ldap without override_attribute,
the user would simply be denied).

The problem with the override_attribute option in nss_ldap is that it
forces ALL users to use the same shell on the system. It ignores their
central selection, even if that shell was available.

So my view is that your LDAP entries are wrong and should be fixed. That
said, I do see at least two possibly valid case for being able to veto a
shell as a login shell. If dash (a variant of the bourne shell used for
scripts but not logins) is present in /etc/shells for support of some
scripts on the system, we probably want to be able to ensure that it is
never used as a login shell by any user (since it's not designed to
handle this well). Granted, that's still probably another case of the
user in LDAP being misconfigured.

The second possibility is that some platforms may have an implementation
of a particular shell with serious known issues (for example, a copy
of /bin/tcsh that does not in fact include the full tcsh extensions to
csh). If an OS contains such a known-broken shell that it cannot remove
for one reason or another (such as support for a broken legacy script),
we'd want to be able to forcibly veto this as well.

So, I suppose I'm willing to see this added. John, would you be willing
to do the legwork on this if we show you where things need to be added?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110729/7ea07c9c/attachment.sig>


More information about the sssd-devel mailing list