Learn more about these different git repos.
Other Git URLs
nss_ldap provides a trivial way to force a shell to users:
nss_override_attribute_value loginShell /bin/bash
However, with SSSD if the shell option is not populated in LDAP the shell users will get depends on libc, usually being /bin/sh and no way for an administrator to force a certain shell.
SSSD should allow "easily" to force a certain shell for all users, regardless of LDAP configuration.
milestone: NEEDS_TRIAGE => SSSD 1.9.0
"Nice to have" for 1.9.
milestone: SSSD 1.9.0 => SSSD Deferred
rhbz: => 0
Moving back to NEEDS_TRIAGE. We should consider implementing this as part of the AD Provider effort, since we do need to handle situations where the user has no shell attribute set.
I'm not convinced we want to force ALL users to a single shell, though. Perhaps we could take a middle-ground approach and add an option to specify the shell to use if-and-only-if there is no shell specified in LDAP.
milestone: SSSD Deferred => NEEDS_TRIAGE
can you explain your use case a bit more. If there is really no shell defined for the user sssd currently uses the glibc fallback as you described. We opened #1289 to add an sssd option here to allow more flexibility.
If this is your use case then I think this ticket can be closed and #1289 can be used, because I think it is at least surprising if some users do not have a shell all other shells are overwritten with a default shell.
If you are looking for a way to overwrite a shell from the central server which is not available on the local system, you can use the vetoed_shells and shell_fallback option to replace non-existing shells. In this case I think the ticket can be close as well.
Are there any other cases where it would make sense to overwrite the shell value for all users?
I was looking for a way a) to define a shell if not defined on the central server and b) to override the centrally defined shell. Case a) seems to be solved with #1289.
For case b), if the central server has /bin/bash for everyone, a power user might prefer /bin/zsh instead on his personal system (the change would be a one-liner in sssd.conf instead of the need for the user to convince corporate administrators to have him one-off setting for shell on the central server) or an administrator might want to force /bin/rbash on certain restricted servers regardless user wishes or preferences.
So a way to overwrite a shell from the central server which is available on the local system seems to be missing.
milestone: NEEDS_TRIAGE => SSSD 1.10 beta
rhbz: 0 =>
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=811995
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=811995 811995]
even case b can be handled with the current set of options. For your first example the power user can say
vetoed_shells = /bin/bash
shell_fallback = /bin/zsh
and for the second example you can put only /bin/rbash to /etc/shells or put all shells on the server in vetoed_shells and use
shell_fallback = /bin/rbash
To make it easier to catch all shells on the server we might want to add a keyword like 'ALL' to the evaluation of vetoed_shell, but there is no new option needed.
I just tried the solution you suggested for the power user case and it didn't work.
I think having /bin/rbash only in /etc/shells is not feasible as that would affect local users, including system users which have /bin/bash as their shell, e.g., the MySQL user. Also, from system administration point of view it would be more feasible to allow this only by configuring sssd.conf (as is the case with nss_ldap).
milestone: SSSD 1.10 beta => SSSD 1.9.0 beta 3
Ok, after some IRC discussios and additional testing it turned out that the vetoed_shells/shell_fallback work as expected under the nss configuration section, they're not per-domain options. And since they do not affect local users, /bin/rbash should do the trick as shell_fallback as well for any LDAP user.
So it leaves us only with the 'ALL' case to veto all possible shells and force the use of shell_fallback. I'll leave it up to you whether you think it would be a worthwhile addition.
owner: somebody => sgallagh
status: new => assigned
patch: 0 => 1
resolution: => fixed
status: assigned => closed
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=845638 (Red Hat Enterprise Linux 6)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=811995 811995] => [https://bugzilla.redhat.com/show_bug.cgi?id=811995 811995], [https://bugzilla.redhat.com/show_bug.cgi?id=845638 845638]
Metadata Update from @myllynen:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.9.0 beta 6
to comment on this ticket.