PATH overwritten by /etc/zsh/zshrc

Support
1

I saw safe-rm (the package) installed in Kicksecure and was trying to test that when I discovered that my PATH doesn’t actually contain it:

% echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

A bit of digging led me to this line in /etc/zsh/zshrc

## Use root path from /etc/profile so programs in /sbin are highlighted in green
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Since zshrc runs after zprofile, this line, upon each interactive zsh shell, overwrites all PATH modifications done so far, including /etc/profile.d/safe-rm.sh, which I believe was sourced much earlier by greetd upon login. (Even if I copy / symlink this file to /etc/zprofile.d, the modifications to PATH still won’t survive the line in zshrc above.)

Per self-support-first policy, I tried to workaround this myself, but I wasn’t able to undo this in ~/.zshrc. Despite home being sourced later than etc, once the PATH is overwritten there’s no easy way to restore it or even know the previous value. I thought about editing /etc/zsh/zshrc but once I do this I’ll miss all future Kicksecure updates to this file, which may bring more security or usability features. I also thought about hard-coding my own PATH but that won’t reflect future changes to /etc/profile.d and /etc/zprofile.d automatically.

I also believe this problem is specific to Kicksecure (and Whonix) since this file came from one of Kicksecure APT packages, usability-misc. This problem is not reproducible in Debian.

Q: As a user, is there a good (clean) way to workaround this and preserve $PATH, or should this be patched by the Kicksecure distro?

One final thought: How important / useful is it to highlight programs in /sbin in green? Those are programs I normally won’t invoke unless with sudo. But sudo <command> makes the whole line magenta so the green won’t show anyway.

ZSH_HIGHLIGHT_PATTERNS+=('sudo*' 'fg=magenta')
2 Likes
Kicksecure 18.2.1.9 - Point Release!
2

We talked a bit about this internally, I don’t think we came to a good conclusion about whether preserving this is a good idea or not. Packages injecting things into $PATH is a bit weird, but on the other hand overriding it results in issues like what you’re seeing.

Can you just source /etc/profile.d/safe-rm.sh in ~/.zshrc? It’s true that you won’t be able to restore the old $PATH exactly as it was pre-overwrite, but you can always augment it post-overwrite, and all /etc/profile.d/safe-rm.sh does is augment $PATH.

I think the comment there is somewhat misleading. Having /sbin in $PATH is useful for more than just highlighting, it’s also useful so that people can just run shutdown now rather than /sbin/shutdown now and the like. Changing this to be more like Debian (requiring /sbin/shutdown now) might have technical merit, but we’ll probably frustrate users who are used to just typing shutdown now.

2 Likes
3

There are 2 different topics.

  • A) How users can reliably configure environment variables without packages reverting with these.
  • B) How Linux distribution developers can reliably configure environment variables without packages reverting with these.

As a user you should at least be able to use /etc/environment. Does it work for you? Packages are not allowed to touch it. At least Kicksecure won’t touch it. It’s not a written down policy yet. But it is obvious in my mind. Dev/About Debian Packaging should lead to that conclusion. Can be more explicit in the future.

Even custom packages outside of Kicksecure and packages.debian.org should not modify /etc/environment. But if they do, yeah, hope they don’t mess up user environment variables.

I would like to say, use drop a snippet in folder /etc/environment.d but unfortunately on Linux /etc/environment versus /etc/environment.d is inconsistent, messy and weird.

Matches my knowledge.

Information for developers:

Related:

pam_env:

In Debian src/pam/1.7.0-5/meson.build file might be the reason why Debian pam_env does not enable /etc/environment.d by default.

if libeconf.found()
  cdata.set('USE_ECONF', 1)

But the debian/control file lacks Build-Depends: libeconf.

Debian feature request:
enable pam_env /etc/environment.d support

4

It works in the sense that the PATH env var can be set and modified (in the compositor and other programs). But that doesn’t help with my use case, which is, running commands in a terminal emulator running zsh. As explained above, when zsh starts, it reads /etc/zsh/zshrc, which overwrites PATH, so the environment setup so far (regardless of method) are effectively ignored. /etc/environment.d/*.conf and its equivalent in $HOME is helpful for other env vars though.

EDIT to clarify: Suppose I change my terminal emulator to run bash instead of zsh, then yes the environment variable updates so far are inherited, not overridden, and works as expected. It’s only zsh . I earlier said “overwrite” but it’s probably not the the right word. It’s more like a local override that only works for that one zsh program and whatever spawned from it, but that’s enough to ruin the experience for the majority of use cases. (Don’t get me wrong, I don’t want to change back to Bash)

1 Like
5

This works for my use case. Consider my problem solved. The rest of this post is just some personal opinions while we’re at the topic.

As a user, I’d vote for adding /sbin to PATH without removing other things in PATH. That’d be a pure usability improvement for me.

On the topic of safe-rm, it’s quite surprising that Kicksecure comes with safe-rm preinstalled but it doesn’t work most of the time because of a side-effect of another line in another distro config. Especially so when safe-rm is supposed to protect me from silly mistakes by default but I have to deliberately re-enable it in an obscure way. As a user, this kinda feels like a regression during Kicksecure moving from bash to zsh as the default shell.

With that being said, I appreciate the move to zsh overall and I really love how the Kicksecure team spent a lot of time shipping usability improvements by default.

2 Likes
6

We might be able to fix this by no longer force overwriting PATH.

Developer information:

Replacing rm with safe-rm might be a bit heavy and break things. For safe-rm as a rm replacement, please create a dedicated forum thread if interested in that.

2 Likes
7

I don’t feel strongly about it. I misunderstood the point of safe-rm being preinstalled. Thanks for your explanation. Now I understand Kicksecure just uses safe-rm as a dependency, as in, Kicksecure scripts call /bin/safe-rm as a binary. It’s not meant to be preinstalled for the end user as a usability improvement. I can agree with that stance.

I think the confusion came from the fact that the Debian safe-rm package focuses quite heavily on the benefits to the end user in the package description. But it in fact has dual intention. There’s no good way to install it just for the binary but not /etc/profile.d/safe-rm.sh. Well, not unless a Kicksecure package adds a diversion.

Debian could have split it into two packages, one for the binary and one for the profile.d stuff but that’s an issue with upstream. We don’t have to debate it here. Maybe the package maintainer don’t see the binary being useful on its own or maybe they don’t like the overhead.

Those topics aside, I only feel strongly about PATH overwrites in zshrc since that’s the only Kicksecure-specific part and it affects more than safe-rm. And that’s the point of this thread I guess.

2 Likes
8

Should be resolved in this commit (pending merge):

1 Like