Another issue:
The ZDOTDIR
environment variable is unset when logging in over SSH.
Results in…
Something useful here that we don’t have yet…?
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.
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.
Cannot be run as root / with sudo either.
unset ZDOTDIR
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?
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.
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
.
Perhaps a symlink from
~/.zshrc
to some file in/etc/zsh/dist
would help here?
Not for vms that created other users…
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
?
Perhaps a symlink from
~/.zshrc
(/home/user/.zshrc
) to some file in/etc/zsh/dist
would help here for useruser
?
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.
https://debathena.mit.edu/config-package-dev/
Contribute to Whonix/anon-ws-disable-stacked-tor development by creating an account on GitHub.
This kind of compromise seems better than missing with user home dir.
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
zcompile [ -U ] [ -z | -k ] [ -R | -M ] file [ name ... ]
zcompile -ca [ -m ] [ -R | -M ] file [ name ... ]
zcompile -t file [ name ... ]
This builtin command can be used to compile functions or scripts,
storing the compiled form in a file, and to examine files contain‐
ing the compiled form. This allows faster autoloading of functions
and execution of scripts by avoiding parsing of the text when the
files are read.
The first form (without the -c, -a or -t options) creates a com‐
piled file. If only the file argument is given, the output file
has the name `file.zwc' and will be placed in the same directory as
the file. The shell will load the compiled file instead of the
normal function file when the function is autoloaded; see the sec‐
tion `Autoloading Functions' in zshmisc(1) for a description of how
autoloaded functions are searched. The extension .zwc stands for
`zsh word code'.
If there is at least one name argument, all the named files are
compiled into the output file given as the first argument. If file
This file has been truncated. show original
Maybe something even easier but requires compilation
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.
anon-ws-disable-stacked-tor/debian at master · Whonix/anon-ws-disable-stacked-tor · GitHub
This kind of compromise seems better than missing with user home dir.
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?
renamed: etc/zsh/dist/.shrc -> etc/zsh/.shrc renamed: etc/zsh/dist/.zshrc …
https://forums.whonix.org/t/change-default-shell-from-bash-to-zsh-by-default/147…
https://forums.whonix.org/t/change-default-shell-from-bash-to-zsh-by-default/147…
renamed: etc/zsh/.shrc -> etc/zsh/shrc renamed: etc/zsh/.zshrc -> etc/zsh/…
https://forums.whonix.org/t/change-default-shell-from-bash-to-zsh-by-default/147…
Also useful for developers, that’s why I didn’t notice this issue before:
sudo rm -r /etc/zsh/dist
Working great, awesome. Just noticed a regression to aliasrc, probably file name, will fix.
Thanks, merged!