Problem
The safe_source function in .zshrc is too restrictive and rejects:
- Files with permission
664 (group-readable/writable)
- Root-owned system files in
/usr/share/
This causes aliases and zsh plugins to fail silently on freshly provisioned VMs.
Symptoms
Warning: /home/user/.dotfiles/.aliases has insecure permissions (664)
Warning: /home/user/.dotfiles/distro/debian/.aliases_debian has insecure permissions (664)
Warning: /usr/share/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh not owned by user (owner: root)
Warning: /usr/share/zsh-autosuggestions/zsh-autosuggestions.zsh not owned by user (owner: root)
Result: l alias (and all other aliases) don't work.
Root Cause
In .zshrc line 69:
if [[ "$perms" =~ [2367]$ ]] || (( 10#$perms > 644 )); then
This rejects 664 because 664 > 644, but 664 is a valid permission (group read+write, no world write).
Additionally, the ownership check rejects legitimate system files owned by root.
Proposed Fix
Fix 1: Adjust permission check
# Old (too strict - rejects 664):
if [[ "$perms" =~ [2367]$ ]] || (( 10#$perms > 644 )); then
# New (allow 664, still reject world-writable like 666, 777):
if [[ "$perms" =~ [267]$ ]] || (( 10#$perms > 664 )); then
Fix 2: Allow root-owned system files
# After the owner != USER check, add exception:
if [[ "$owner" != "$USER" ]]; then
# Allow root-owned files in system directories
if [[ "$owner" == "root" && "$file" == /usr/share/* ]]; then
: # OK - system file
else
echo "Warning: $file not owned by $USER (owner: $owner)" >&2
return 1
fi
fi
Workaround
Until fixed, manually adjust permissions:
chmod 644 ~/.dotfiles/.aliases ~/.dotfiles/distro/debian/.aliases_debian
Environment
- Discovered on: Ubuntu VM provisioned via vm-infra
- Shell: zsh with XDG-compliant dotfiles setup
Problem
The
safe_sourcefunction in.zshrcis too restrictive and rejects:664(group-readable/writable)/usr/share/This causes aliases and zsh plugins to fail silently on freshly provisioned VMs.
Symptoms
Result:
lalias (and all other aliases) don't work.Root Cause
In
.zshrcline 69:This rejects
664because664 > 644, but664is a valid permission (group read+write, no world write).Additionally, the ownership check rejects legitimate system files owned by root.
Proposed Fix
Fix 1: Adjust permission check
Fix 2: Allow root-owned system files
Workaround
Until fixed, manually adjust permissions:
Environment