#2219 Shell fallback mechanism in SSSD
Closed: Fixed None Opened 5 years ago by dekutin.

At this moment shell fallback mechanism in SSSD works a bit complex. Before it can be used you need to point in sssd.conf parameter allowed_shells. This parameter used for enumerate shells for which SSSD will use its shell fallback.
It's not very convenient when you got huge heterogeneous network for different projects with different administrators. It seems shells(5) would be enough to indicate whenever SSSD need to use fallback shell.

To resolve this problem I contributed a tiny patch https://lists.fedorahosted.org/pipermail/sssd-devel/2014-January/018265.html "it's not pretty but it got it going on"


Hi, I'm sorry for the very late reply. I'd like to follow up on the conversation we had on sssd-devel, in particular:

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.

In my opinion, you don't have to use any of the shell parameters at all. What is the difference between using your new parameter which says "use anything from /etc/shells" and just omitting the parameters at all?

If you omit the parameters like allowed_shell or shell_fallback and a user with an illegal shell comes in, he would be kicked out. If his shell is valid, he would be allowed.

Sorry, maybe I'm not seeing your exact use case, can you explain once more?

Ok, let me try another form of expression my thoughts: http://yadi.sk/d/zUgiRmr3K458W
We have 2 hosts with default sssd parameters (allowed_shells, shell_fallback), on the host A there is zsh, on the other it's absent. And there is a user who used zsh. At this moment he can login to host A, and can't login to host B.
To fix this we need a) install zsh on host B or b) specify zsh in allowed_shells parameter ( or с) force user to change his shell ).

But when there are ten thousands of hosts and hundreds of users it's really hard to control this. Actually, we use both methods: we have meta-package which install a great deal of shells. Also we use special script which find in ldap all shells and specified them in allowed_shells (jfyi, at this very moment it looks: allowed_shells = /bin/bash, /bin/csh, /bin/false, /bin/tcsh, /bin/zsh, /usr/bin/fish, /usr/bin/zsh, /usr/local/bin/bash, /usr/local/bin/zsh ).

So this patch add new logic to existed one with shell_fallback mechanism "if shell exists on a host - use it, if not - use fallback"

Ah, thank you for explanation, now it makes sense. I just wonder if it would make more sense to extend shell_fallback semantics. But I agree with this use case.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12 beta
rhbz: => todo

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.12 beta 2

This patch needs a bit more discussion and review, sorry. Moving to 1.12.1 since 1.12.0 will be frozen for translations.

milestone: SSSD 1.12 beta 2 => SSSD 1.12.1

Fields changed

design: => N/A not needed

Do you need any help from me?

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

Fields changed

owner: somebody => preichl
status: new => assigned

We need to do a release as requested by downstream. Moving tickets that are not fixed already or very close to acking to 1.12.3

milestone: SSSD 1.12.2 => SSSD 1.12.3

Fields changed

mark: => 0
patch: 0 => 1

resolution: => fixed
status: assigned => closed

Metadata Update from @dekutin:
- Issue assigned to preichl
- Issue set to the milestone: SSSD 1.12.3

2 years ago

Login to comment on this ticket.

Metadata