Learn more about these different git repos.
Other Git URLs
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"
attachment 0001-Possibility-to-use-any-shells-in-allowed_shells.patch
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.
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
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
design: => N/A not needed
Do you need any help from me?
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1137014
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1137014 1137014]
Mass-moving all tickets that didn't make 1.12.1 into 1.12.2
milestone: SSSD 1.12.1 => SSSD 1.12.2
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
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
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3261
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.