Issue #2219: Shell fallback mechanism in SSSD - sssd

SSSD / sssd

#2219 Shell fallback mechanism in SSSD

Closed: Fixed None Opened 10 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"

dekutin commented 10 years ago

attachment
0001-Possibility-to-use-any-shells-in-allowed_shells.patch

jhrozek commented 10 years ago

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?

dekutin commented 10 years ago

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"

jhrozek commented 10 years ago

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.