Change default shell from bash to zsh by default?

1 Like

Thanks, merged!

Another issue:
The ZDOTDIR environment variable is unset when logging in over SSH.

Results in…

Something useful here that we don’t have yet…?

Will review later.

1 Like

2 posts were split to a new topic: more secure shell version called experimental - ash - reduced attack surface

autoload -U zsh-newuser-install
zsh-newuser-install -f

zsh-newuser-install: can’t write to /etc/zsh/dist.
zsh: exit 1

No root permissions, that is why… don’t know yet how to deal with it.

1 Like

Cannot be run as root / with sudo either.


might help. zsh-newuser-install can then be run but I am not sure the created configuration files would be ignored next time a new shell is opened?

Maybe the same question in other words: Does our current ZDOTDIR based approach support user customization made in user home’s folder?

Current configuration does not support user configuration to home directory.

1 Like

To solve the SSH issue, maybe a bit late now but maybe back to the drawing board.

The function will be run again next time. To prevent this, execute:
touch ~/.zshrc

How can we avoid such corner cases?

Does file ~/.zshrc allow for a different implementation path?

Could we drop the ZDOTDIR environment variable? But that’s not the main goal. That would just be a bonus.

Perhaps a symlink from ~/.zshrc to some file in /etc/zsh/dist would help here?

ln -s /etc/zsh/dist/.zshrc /home/user/.zshrc

I know I said it’s best to avoid writing into the user home folder before.
(Dev/About Debian Packaging - Kicksecure)
But a symlink only might be a good compromise. It’s easy for the user to remove if the user wishes to customize. (unlink /home/user/.zshrc)

For for package desktop-config-dist it would be easy to update zsh configuration files in folder /etc/zsh/dist. Since no actual scripts are in user home folder, to dpkg interactive conflict resolution dialog will happen since the scripts are nicely contained in /etc/zsh/dist.

Not for vms that created other users…

1 Like

You mean multi-user environments such as user2, user3, i.e. /home/user2, /home/user3? Indeed.

The symlink cannot easily be created on a multi user system. But I might find a solution for that. (Similar to security-misc’s home folder permission lockdown.)

Ignoring the multi-user issue…

Perhaps a symlink from ~/.zshrc (/home/user/.zshrc) to some file in /etc/zsh/dist would help here for user user?

Only for that user, yes…

Can we do a package anon-zsh that Provides: zsh and patches the /etc/zsh/zshrc by appending source /etc/zsh/dist/.zshrc? What is the problem with that? Seem bulletproof.

This kind of compromise seems better than missing with user home dir.

1 Like

Maybe something even easier but requires compilation

Any of these files may be pre-compiled with the zcompile builtin com‐
mand (see zshbuiltins(1)). If a compiled file exists (named for the
original file plus the .zwc extension) and it is newer than the origi‐
nal file, the compiled file will be used instead.

If we combile the zsh files, it will be newer than the system ones and will be used instead… seems much better

1 Like

Also an option but I think harder to understand then config-package-dev method. Because then we need to add the compilation at some step (postinst script) but the source files in /etc/zsh wouldn’t correspond to the script files. And user making changing would also require surprising documentation.

Yeah. At this point with the remaining issues (Zsh prompt after SSH login (for Kicksecure servers), ZDOTDIR “stolen” from user, zsh-newuser-install broken)…

Best to avoid melding in user’s home folder. Environment variables approach also non-idea (above issue). So config-package-dev it is. Kali is also using dpkg diversions.


Will implement this soon.

This is now implemented. Could you have a look please if all is still working as before?