this post was submitted on 15 Aug 2023
41 points (100.0% liked)

Linux

48012 readers
869 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Hi all I have a quick question. Is it better for my zsh shell to be in /usr/bin/zsh or /bin/zsh. I remember reading that one of them would mess up the whole system since zsh is not posix compliant. I believe that szh shouldn't be set as the root shell. I now have it in /usr/bin/zsh, is that good? So now when I drop into a root shell I don't get they autocompletion feature that zsh has. I'd also lose that fancy theme. Does that mean my root shell is still bash? Thanks

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 19 points 1 year ago (2 children)

As long as /bin/sh isn't pointing to zsh, you haven't messed anything up. A lot of public scripts wouldn't expect to be run under zsh.

If you write your own scripts, I'd say to use zsh, but start it with #/bin/zsh (or whatever resolves to zsh) to be explicit about the fact that it is designed for zsh and nothing else. Most scripts written aren't going to be distributed to hundred of thousands of systems, but at most used in a handful of systems. No point in not enjoying some things zsh does better in scripts.

A lot of systems have other dependencies as well, and as long as a system which has scripts in it is specifing zsh along with other dependencies, I wouldn't see the problem. zsh doesn't take up much space or introduce other problems just by being installed.

As for the root shell, you can put Defaults env_keep += HOME in your sudo configuration. That will have sudo -s run your usual zsh with its usual configuration for interactive, daily use. Be aware of any config that shouldn't be run as root.

sudo -i will still run the shell root is assigned in /etc/passwd, and everything run as root would function ar expected.

[–] [email protected] 9 points 1 year ago* (last edited 1 year ago) (1 children)

#!/usr/bin/env zsh is better for portability/compatibility. You can set the root shell as whatever you want (including zsh). Leaking the user context with sudo -s is generally a bad idea. Unless you actually share a system with multiple users, I'd advise to set a root password and use su - in favor of sudo -i or sudo -s. Two (proper) passwords are more secure than one.

edit: typo

[–] [email protected] 3 points 1 year ago (1 children)

My collegues wouldn't appreciate my shell config in the root account, especially the vi bindings ;)

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

I understand the motivation of using the user environment in the root context. It's still a bad idea. The assumption is, that it is easier to compromise a non-privileged desktop user than the root account. Imagine some exploit breaking out of a sandbox and doing some minor modifications to your $HOME: either aliasing ls to a script somewhere in your home by changing your profile or some shell rc file, or prepending your $PATH environment variable with a folder burried somewhere in your home directory where a script ls is placed:

#!/usr/bin/env sh

if (( $EUID == 0 )); then
    # do something evil here
fi

\ls "$@"

Now, as an attacker you just wait for some admin on a shared system to come along and use sudo -s.

[–] [email protected] 6 points 1 year ago

zsh is supposed to emulate sh as closely as possible if it is called by that name (it can also be ksh, according to its manual), so I wouldn't be too concerned even if that did happen.

(bash can do the sh trick too. Many(?) distros don't actually use the bigger shells for that and install something like dash - a pure POSIX shell with no other bells and whistles - to act as sh when called that way.)

Other suspect configurations might not be as fortunate, but this one is fine.