[SSSD] [PATCH] allowed_shells: using wildcard for any shell (Jakub Hrozek)

Denis Kutin deniskutin at gmail.com
Mon Feb 3 15:42:47 UTC 2014


> On Thu, Jan 30, 2014 at 02:35:57PM +0400, Denis Kutin wrote:
> > Dear friends,
> >
> > Using sssd, for a long time, I have come across with a problem recently,
> > which I would like to solve with your help.
> >
> > I provide centralized authentication and authorization service for a huge
> > heterogeneous network. And in my case it would be "nice and easy" if sssd
> > used only shells(5). I believe this mechanism is sufficient for
> > identification of an allowed shell.
> >
> > I take a liberty to offer you this tiny patch, which will let use
> wildcard
> > (*) in param allowed_shells in sssd.conf
> >
> > What do you think about it?
>
> Hi,
>
> the patch itself looks OK except for lines being over 80 characters,
> but I don't think I understand the use case well. If a user has a shell
> specified that is outside /etc/shells he's kicked out anyway. If he does,
> he's permitted by default..
>

Not exactly. SSSD has a shell_fallback  If user has a shell specified that
is outside of /etc/shells, SSSD checks allowed_shell parameter. If user's
shell is in allowed_shell, then SSSD fallback to shell_fallback, otherwise
user kicked out.

Here, from sssd.conf(5)
           1. If the shell is present in "/etc/shells", it is used.

           2. If the shell is in the allowed_shells list but not in
"/etc/shells", use the value of the shell_fallback parameter.

           3. If the shell is not in the allowed_shells list and not in
"/etc/shells", a nologin shell is used.

At this moment I need to generate sssd.conf dynamically, specified all
existed (in our environment) shells.

-- 
Denis Kutin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20140203/828b7148/attachment.html>


More information about the sssd-devel mailing list