New users created by wikitech should also be set to /bin/bash rather than sillyshell

Change 184635 had a related patch set uploaded (by Yuvipanda):
Make wikitech default shell sillyshell

https://gerrit.wikimedia.org/r/184635

Patch-For-Review

Sillyshell, for those unaware, was a dead-simple shell that wrapped svnserve & co. and we used to run it on the Subversion box. We committed using svn+ssh but didn't want to give people fully interactive shells.

Any remaining references to sillyshell should get cleaned up.

See also T67591 (maybe duplicate). IIRC the two questions there were:

1. Don't accidentally unlock the Subversion server for anyone with shell access.
2. Don't accidentally lock the Subversion server for ops.

In T86668#974281, @scfc wrote:

See also T67591 (maybe duplicate). IIRC the two questions there were:

1. Don't accidentally unlock the Subversion server for anyone with shell access.
2. Don't accidentally lock the Subversion server for ops.

1. Isn't a problem because the permissions on the repos are all read-only, regardless of who you are

In T86668#974333, @Chad wrote:

In T86668#974281, @scfc wrote:

See also T67591 (maybe duplicate). IIRC the two questions there were:

1. Don't accidentally unlock the Subversion server for anyone with shell access.
2. Don't accidentally lock the Subversion server for ops.

1. Isn't a problem because the permissions on the repos are all read-only, regardless of who you are

Yes, but if previously the server was set up with the mindset that non-trusted users can only execute svnserve -t, allowing users full shell might open up new attack vectors. I don't know if the Subversion server is treated security-wise in the same way as a Labs instance.

If we do T86674: Migrate leftover old svn content to a readonly repo somewhere/T86655: Decommission svn.wikimedia.org server (import SVN into Phabricator) this won't be a problem

Change 184635 merged by jenkins-bot:
Make wikitech default shell /bin/bash

https://gerrit.wikimedia.org/r/184635

antimony, our svn server, doesn't actually seem to have LDAP configured, or ssh accessible from outside the cluster.

Change 185127 had a related patch set uploaded (by Yuvipanda):
labs: Don't override shell for all users

https://gerrit.wikimedia.org/r/185127

Patch-For-Review

Change 185127 merged by Faidon Liambotis:
labs: Don't override shell for all users

https://gerrit.wikimedia.org/r/185127

I suspect https://gerrit.wikimedia.org/r/#/c/185127/ changed the mwdeploy user homedir as a side effect, but that might be unrelated.

Beta cluster scap is broken: T86901
I have filled a bug to change mwdeploy homeDirectory in LDAP T86903

Change 299812 had a related patch set uploaded (by Chad):
add-ldap-user: Don't use sillyshell, it's silly (and doesn't exist anymore)

https://gerrit.wikimedia.org/r/299812

Change 299812 merged by Yuvipanda:
add-ldap-user: Don't use sillyshell, it's silly (and doesn't exist anymore)

https://gerrit.wikimedia.org/r/299812

Was this completed?

krenair@bastion-01:~$ ldapsearch -x "(&(objectClass=novauser)(!(loginShell=/bin/bash)))"
# extended LDIF
#
# LDAPv3
# base <dc=wikimedia,dc=org> (default) with scope subtree
# filter: (&(objectClass=novauser)(!(loginShell=/bin/bash)))
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
krenair@bastion-01:~$ ldapsearch -x "(&(objectClass=novauser)(loginShell=/bin/bash))" | tail -n 2
# numResponses: 572
# numEntries: 571

Ugh, wrong objectClass:

krenair@bastion-01:~$ ldapsearch -x "(&(objectClass=person)(!(loginShell=/bin/bash)))" | grep dn: | grep ou=people | grep -v servicegroups | grep -v "tools\."
dn: uid=river,ou=people,dc=wikimedia,dc=org
dn: uid=shinken,ou=people,dc=wikimedia,dc=org
krenair@bastion-01:~$ ldapsearch -x uid=shinken | grep loginShell
loginShell: /bin/false
krenair@bastion-01:~$ ldapsearch -x uid=river | grep loginShell
loginShell: /usr/bin/zsh

There are only two account in LDAP with shells not being /bin/bash:

$ ldapsearch -LLL -x -b 'ou=people,dc=wikimedia,dc=org' "(&(objectClass=person)(!(loginShell=/bin/bash)))" dn loginShell
dn: uid=river,ou=people,dc=wikimedia,dc=org
loginShell: /usr/bin/zsh

dn: uid=shinken,ou=people,dc=wikimedia,dc=org
loginShell: /bin/false

river is no more active iirc and shinken I am not sure why would need false. I guess LDAP-Access-Requests can change the shell for both of those users to /bin/bash.

Most probably we can then remove the nslcd.conf override in modules/ldap/templates/nslcd.conf.erb:

<%- if @shell_override %>
map passwd loginshell "<%= @shell_override %>"
<%- elsif @realm == "labs" %>
map passwd loginshell "/bin/bash"
<%- end %>

And the task would be completed.

In T86668#3234234, @hashar wrote:

There are only two account in LDAP with shells not being /bin/bash:

$ ldapsearch -LLL -x -b 'ou=people,dc=wikimedia,dc=org' "(&(objectClass=person)(!(loginShell=/bin/bash)))" dn loginShell
dn: uid=river,ou=people,dc=wikimedia,dc=org
loginShell: /usr/bin/zsh

dn: uid=shinken,ou=people,dc=wikimedia,dc=org
loginShell: /bin/false

This result ignores the 970 posixaccount objects under ou=people,ou=servicegroups,dc=wikimedia,dc=org that use /usr/local/bin/sillyshell or /bin/false:

$ ldapsearch -xLLL -E pr=40000/noprompt -b 'dc=wikimedia,dc=org' '(&(objectClass=posixaccount)(!(loginShell=/bin/bash)))' loginShell |grep loginShell|sort|uniq -c
      2 loginShell: /bin/false
      1 loginShell: /usr/bin/zsh
    969 loginShell: /usr/local/bin/sillyshell

Most of these (soon to be all I think based on recent email threads) are Tool Labs "tool" shared accounts. These are the users that actually run jobs on the job grid and the accounts that become $TOOLNAME sudo's the calling user to. They will all need to be fixed before the remapping is removed from nslcd.conf in Tool Labs. I've made a note in T149458: Manage shared tool accounts via Striker that I should not propagate the /usr/local/bin/sillyshell to new tools accounts. There is probably something we can change in MediaWiki-extensions-OpenStackManager to stop that sooner as well.

I am not sure why would need false.

This is a service account that is in LDAP for $REASONS. I haven't bothered to track down what those reasons are. Having it's shell set to /bin/false is perfectly fine though and will do what it is intended to do (stop interactive logins as this user) once the hack in our config is removed. For that matter its fine for river to have zsh as a login shell. We just need to have all accounts have valid login shells so we can remove the hack in nslcd.conf that replaces the loginshell reported by LDAP with /bin/bash unconditionally.

I have excluded the servicegroups based on an earlier comment.

/bin/false looks legit indeed. Thanks.

I have dig in puppet history about add-ldap-user:

The script defaulted to sillyshell. That got switched to default to bash ( 601cb5464fd6f3c42840e18fd17e3755ae9fbf0f / T86668 ).

c3457c9d6b removed the script entirely since You create ldap users with wikitech now.

But I have not been able to find any reference to sillyshell :(

And OpenStackManager uses /bin/bash 6360ed954ee5488d0a4be3bcc156bdc0bc7543f4

-$wgOpenStackManagerLDAPDefaultShell = '/usr/local/bin/sillyshell';
+$wgOpenStackManagerLDAPDefaultShell = '/bin/bash';

So most probably we just have to do an LDAP search and replace for the service groups?

Sillyshell entries can probably be replaced with /bin/bash, it doesn't exist anymore. It was a dummy wrapper that we used for SVN that limited what things a user could do over SSH, namely just SVN-related stuff.

The summary is roughly:

Only service groups still have sillyshell as a login. OpenStackManager is no more adding it and defaults to bash.

Account left to migrate are the various service groups (969 of them):

bastion.wmflabs.org$ ldapsearch -xLLL -E pr=40000/noprompt -b 'dc=wikimedia,dc=org' '(&(objectClass=posixaccount)(!(loginShell=/bin/bash)))' loginShell |grep loginShell|sort|uniq -c
      3 loginShell: /bin/false
      1 loginShell: /usr/bin/zsh
    969 loginShell: /usr/local/bin/sillyshell
bastion.wmflabs.org$

Is it fine to switch the to /bin/bash and who can handle the LDAP queries to rewrite them?

Mentioned in SAL (#wikimedia-operations) [2017-06-26T22:49:28Z] <bd808> Updated LDAP loginShell to /bin/bash for 969 accounts that were still set to /usr/local/bin/sillyshell (T86668)

The sillyshell entries have been cleaned up.

$ ldapsearch -xLLL -E pr=40000/noprompt -b 'dc=wikimedia,dc=org' '(&(objectClass=posixaccount)(!(loginShell=/bin/bash)))' loginShell |grep loginShell|sort|uniq -c
      3 loginShell: /bin/false
      2 loginShell: /usr/bin/zsh

Change 361595 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[operations/puppet@production] nslcd: Remove Labs shell override

https://gerrit.wikimedia.org/r/361595

Thank you @bd808 !

Just for the historical record, here's what I did to edit the loginShell entries. Commands were run from labcontrol1001.wikimedia.org:

$ for dn in $(ldapsearch -xLLL -E pr=40000/noprompt -o ldif-wrap=no -b 'dc=wikimedia,dc=org' '(&(objectClass=posixaccount)(loginShell=/bin/zsh))' dn|grep dn:|awk '{print $2}'); do
(
echo dn: $dn
echo changetype: modify
echo replace: loginShell
echo loginShell: /bin/bash
echo
) >> T86668-fix-shells.ldif
done
$ view T86668-fix-shells.ldif
$ ldapmodify -x -D 'uid=novaadmin,ou=people,dc=wikimedia,dc=org' -W -f T86668-fix-shells.ldif
Enter LDAP Password:

The use of -o ldif-wrap=no in the initial search is important. There are many dn values that are rather long and would otherwise be wrapped to multiple lines that break the grep + awk extraction. In this particular case, I don't think the use of -E pr=40000/noprompt to enable paging by the client was strictly necessary, but it doesn't hurt anything.

Change 361595 merged by Andrew Bogott:
[operations/puppet@production] nslcd: Remove Labs shell override

https://gerrit.wikimedia.org/r/361595