Question may be not clear and too broad, but any answer, however short or broad it may be, is very appreciated.

Some time ago I've asked to install zsh on our production server. My admins companies replied that it cannot be done since this is production, not dev server.

I used zsh & oh-my-zsh for last 5 years and am very attached to it, zsh makes my work easier and faster. But it wasn't the enough argument.

I am not strong in security or other issues that may be involved here, that's why my questions are:

  1. Is installing zsh on production server harmless to the system?
  2. Would you allow to install zsh in this case, and why so?
  3. Does it make sense to restrict users with bash on production server?

closed as primarily opinion-based by Jeff Schaller, JdeBP, schily, jasonwryan, sebasth Aug 27 '18 at 19:29

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    You were right with the "too broad" fears -- every administrator deals with their local policies and preferences. Minimizing installed software is a good idea from a security standpoint; if you can't get a shell installed "globally", you could look into installing/running it on your own account. – Jeff Schaller Aug 27 '18 at 16:14
  • 1
    Faced with supporting hundreds / thousands of 'standard' servers, and a single user wanting a new rpm introducing because "makes his work easier and faster" I can understand how the admin team didn't sanction its introduction. – steve Aug 27 '18 at 16:48
  • 1
    It's also too broad because not only is it three questions in one the assumption in question #3 is fallacious. Question #2 is, moreover, soliciting people's personal opinions, without your even providing a proper detailed account of what "this case" is apart from a vague paraphrase of what you were told, which could actually be one of several different local adminstrative policies. There is no objectively measurable way for people to determine a right answer, which is what this WWW site is (supposed to be) based around. – JdeBP Aug 27 '18 at 18:30

zsh is just a shell, it doesn't start any service, it doesn't come with any setuid command. So the mere installation of the package is not going to do anything until somebody or something actually uses it. Since it doesn't need any privilege, any user can install it on their own in their home directory or wherever they have access to.

If it wasn't production quality, one could argue that making it the login shell of and admin user would introduce some risk, but with its much saner syntax than other shells like bash or tcsh, I would argue that it would improve matters considerably.

Though its primary usage is as an interactive shell, I'd argue that writing scripts in zsh would likely make safer and more reliable scripts than bash scripts (see how many people unknowingly write bash scripts in zsh syntax when they forget to quote their variables and how changing the shebang from #! /bin/bash to #! /bin/zsh would fix many of the bugs in their scripts).

In any case, installing zsh is among the first things that I have been doing for all server deployments in all the places I've worked at.

However, I generally don't make it the login shell of any user by default as it's not uncommon for some software to expect a bash-centric environment.


Other opinions available, but here's mine.

  1. Is installing zsh on production server harmless to the system?

Introducing new software is rarely harmless. For example, it comes with the need to ensure any vulnerabilities associated with it are identified and patched.

  1. Would you allow to install zsh in this case, and why so?

No. Would want a tangible benefit to be identified.

  1. Does it make sense to restrict users with bash on production server?

Yes, bash is great :-) And if some niche group of users in the company start writing zsh scripts without the wider support teams having knowledge of it, they're goosed.


In my experience, yes it is uncommon to install zsh on a production server. That being said I work most with more 'conservative' customers (banks, administrations, etc.) so your mileage may vary.

  1. Zsh itself is harmless. It is 'just another shell', like bash, ksh,... However, in many corporations, the security policy is to limit as much as possible the attack surface, i.e. don't install anything unless it's required. Even though zsh is harmless, its code base could contain bugs. Read about Shellshock if you don't already know about it. :)
    That being said, there is a certain leniency for 'commodities' such as having vim instead of just vi. Zsh could fall into this category.

  2. Not in production, not happening. Aside from reducing the attack surface, there's also the fact that you will need to test twice your scripts - once with zsh, once with bash. This takes time and money.

  3. I wouldn't call it restricting to bash: is there anything that you can do with zsh that you can't do with bash?

Final note: bash is pretty much the industry standard. It's the default shell for most enterprise-grade distributions (RHEL, SUSE,...) as well as for many very popular distributions such as Debia, Ubuntun...
I have tried "new" shells over the years: zsh and fish are two that I really liked. For home use maybe, however, at work it's bash all the way (and ksh when working with AIX etc.). I end up using bash at home too, old habits die hard.

  • 1
    2) No, of the scripts start with a #! /bin/zsh they will be only run with zsh and there is no need to test them with bash and Final note) the true "industry standard" is more like ksh (I have seen many Linux shops that still write scripts for ksh). – xenoid Aug 27 '18 at 19:03
  • 1
    Well, it depends, really. If you end up writing script for zsh but you 'only' have bash in production, then you need to test both. As for 'industry standard' this is based on my experience, but everyone differs of course. :) I use to work a lot with ksh on AIX and HPUX, but there are less and less *NIX and more GNU/Linux distros... again, this is my point of view. Your mileage may vary. :) – pi0tr Aug 27 '18 at 19:55
  • No, the industry standard is the actual industry standard, the sh that is standardized in the Single Unix Specification. And that is not the Bourne Again shell on several operating systems, including on Debian and Ubuntu for well over a decade now. unix.stackexchange.com/questions/250913 – JdeBP Aug 27 '18 at 20:14
  • 1
    Alright, didn't mean to start an argument. :) Should probably have said "de facto standard" not "industry standard". – pi0tr Aug 27 '18 at 20:58
  • @piotr No, if you have only bash in production you put a bash shebang and write your scripts for bash (at least all the scripts that go to production). No point making your life complicated if you can't use zsh features. – xenoid Aug 27 '18 at 22:30

Same as the others this is my opinion:

  1. Is installing zsh on production server harmless to the system?

Define 'harmless'. Strictly speaking, it causes no direct harm. However, any code that is on your production system is a potential attack vector. In that sense, it's not truly 'harmless', in that it could be used for an attack on the system. There are also some other ways it indirectly could cause problems. ZSH is a bit more resource hungry than bash for example, which could matter on a system running near capacity.

  1. Would you allow to install zsh in this case, and why so?

Depending on the exact circumstances, I might already have it installed.

All of my personal systems have ZSH installed and set as the default shell for everyone including root. This is simply because I'm pretty regularly working from a local shell on these systems, and I actively use ZSH in many cases.

However, all of the systems I administer at work do not have it installed. About 95% of the administrative work I do for them does not involve me ever actually touching a shell on these systems (I do a lot through Ansible at work), so there's no point in me making it a familiar environment. I'd also be very unlikely to install it on anything but our actual development systems, and there's no chance in hell I'd install it on anything that's directly accessible off-site.

  1. Does it make sense to restrict users with bash on production server?

I'd question the practicality of letting regular users touch production systems at all beyond certain very restrictive cases that do not involve actual shell access.

For example, where I work, only the IT department and the people directly responsible for maintaining our website have anything but regular HTTPS access to our web servers. The IT people (myself included) must log in with a special account only used for administration of the web servers, and even then they have limited access to the systems unless they're sitting at the physical console in the server room. The web designers only have SFTP access to the root of the website, and nothing else. Given this, there is no need for any shell except bash (which is our standard internally for administrative usage).

Similarly, for our internal file servers, only the IT department has actual shell access. Other users have specially limited access to certain directories, usually allowing regular file server protocols (SMB, NFS, etc), plus SFTP, and in some cases rsync, but none of them have any real shell access, because they don't actually need it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.