olets / zsh-abbr

The zsh manager for auto-expanding abbreviations, inspired by fish. ~13,000 unique cloners as of May '24, 580+ Homebrew installs 6/23-6/24
https://zsh-abbr.olets.dev
Other
510 stars 18 forks source link

crash after switching between root and unprivileged users #54

Closed ervinpopescu closed 2 years ago

ervinpopescu commented 2 years ago
_abbr_job_push:add_job:7: permission denied: /tmp/zsh-abbr/jobs/1646859860.17046
_abbr_job_push:wait_turn:3: bad math expression: operand expected at end of string

I don't really know any other way to describe this but segfault :)

'builtin' 'echo' $job_description > ${ABBR_TMPDIR}jobs/$job_name
next_job_age=$(( $(date +%s) - ${next_job%.*} ))

These are the two problematic lines. Looks like the second one is caused by the first. I don't really know what to do about that permission denied. Denied by what? Permissions?

ervinpopescu commented 2 years ago

Solved... I've used the same plugin with the root account and apparently the tmp folder has been modified/created as root. I don't think this is the best practice tho. Do I have to source a different zsh-abbr.zsh?

olets commented 2 years ago

Thanks for the report!

I've used the same plugin with the root account and apparently the tmp folder has been modified/created as root

Aha. That makes sense I think.

The immediate fix is to delete the directory /tmp/zsh-abbr/jobs and then reload the shell (exec zsh). When the plugin initializes it will recreate the directory.

Would be nice if the zsh-abbr handled this case, but my gut says it would be tricky to implement well. Some sort of per-permission-level file, and each session tracks down the right one? Don't want to do anything with changing file permissions, feels like that could open attack vectors.

Instead I think we can work around it with user configuration: in your .zshrc before loading the plugin, customize ABBR_TMPDIR to use a directory that can be read and written to by root and your other user(s):

# ~/.zshrc
ABBR_TMPDIR=some/directory/root-and-nonroot/can-write/to
# and then load zsh-abbr

Let me know if that works!

ervinpopescu commented 2 years ago

The immediate fix is to delete the directory /tmp/zsh-abbr/jobs and then reload the shell (exec zsh). When the plugin initializes it will recreate the directory.

Yep did just that yesterday.

Instead I think we can work around it with user configuration: in your .zshrc before loading the plugin, customize ABBR_TMPDIR to use a directory that can be read and written to by root and your other user(s):

# ~/.zshrc
ABBR_TMPDIR=some/directory/root-and-nonroot/can-write/to
# and then load zsh-abbr

Let me know if that works!

That's an interesting approach. Will test, thanks!

Edit: I need some more help on setting that variable as I'm not entirely sure where that directory should be such that, when root operates on it, it doesn't chown it.

/dev/nvme0n1p5 on / type ext4 (rw,relatime)
/dev/nvme0n1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=4026120k,nr_inodes=1048576,inode64)
/dev/nvme0n1p3 on /mnt/win type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,x-gvfs-show)
/dev/sda2 on /mnt/data type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,x-gvfs-show)
/dev/nvme0n1p6 on /home type ext4 (rw,relatime)

These are my current available partitions. Had some trouble with the ntfs partitions so I changed the ntfs3 driver to ntfs, that's probably why I have fuseblk there. Does the uid=0 and gid=0 mean that I can't use the /mnt/data? Can I use just my $HOME/.cache?

2nd edit:

Could I create a root and user folder in temp and point the respective zsh config to the right folder?

3rd edit xDD:

┌──(ervin@archnet)-[~]
└─$ echo $ABBR_TMPDIR
/tmp/zsh-abbr-user/
┌──(root@archnet)-[/home/ervin]
└─# echo $ABBR_TMPDIR                                                                     
/tmp/zsh-abbr-root/

This seems to work. It also fixes a bug I've been having, the abbreviations were inconsistent when switching from user to root and back:

abbr p="pacman" (root)
abbr p="sudo pacman" (user)

I'm going to close this.

olets commented 1 month ago

Hi @ervinpopescu I revisited this, and built a separate-directories solution in v5.6.0.

Lmk if you'd like to be added to https://github.com/olets/zsh-abbr#community and https://zsh-abbr.olets.dev/community/ for the bug report and thinking through the solution. If so I'll have the all-contributors bot open a pull request. I'll tag you in it, and you'll need to review before I merge to make sure the bot pulled the right info.

ervinpopescu commented 1 month ago

Hi @olets, that sounds great and all, but I really don't think that's needed, the solution for this was mostly driven by you, so I am good with staying in the shadows :)

Thanks for the proposal though!