0

This is my bash script into init.d:

#!/bin/bash
case "$1" in
  'start')
    # mount
    bindfs -n /home/my_user/.local/share/Cryptomator/mnt /home/my_user/drivefolder
 ;;
  'stop')
    fusermount -u /home/my_user/drivefolder
 ;;
  *)
    echo "Usage: $0 { start | stop }"
 ;;
esac

so i run it from root account:

/etc/init.d/drivemount.sh start
/etc/init.d/drivemount.sh stop

What I want is to mount/umount /home/my_user/drivefolder from root account to my_user account without privileges (so that the mounted folder can be manipulated without privileges).

is there any way to do this? (without having to run the script in my_user account without privileges and from another location)

Clarification: The script does not run automatically. What I want is to run the script manually, either from root or from my_user with sudo only from /etc/init.d location (for reasons unrelated to the question)

PD: I have read that with eval it can be done but I don't know.

acgbox
  • 785
  • So you want to run bindfs as my_user? Doesn't sudo -u my_user bindfs … work? – Kamil Maciorowski Jul 10 '21 at 17:27
  • yea. What you say is correct (I suggest you post the full answer), but I add something to it. If I run the script with sudo then I have to use eval sudo -u my_user bindfs bla bla. But it would be necessary to correct the command for umount – acgbox Jul 10 '21 at 17:50
  • I thought the script is in /etc/init.d/ so it runs automatically.Therefore I don't understand "if I run the script with sudo". Why do you want to run it with sudo? Doesn't it run as root automatically? And I totally don't get this "eval" idea. As for unmounting, I think root can fusermount -u anything without sudo. – Kamil Maciorowski Jul 10 '21 at 17:55
  • It does not run automatically. I can program it in cron or run it manually from root or with sudo – acgbox Jul 10 '21 at 18:01
  • So /etc/init.d/ is misleading. – Kamil Maciorowski Jul 10 '21 at 18:02
  • "from my_user with sudo" -- Why with sudo? The whole point seems to be you want to do something as my_user without elevated privileges. My solution in the first comment is simple and (IMO) so obvious. For this reason I did not post an answer, it seemed too easy, I suspected there was something more. And now it seems there is something more, but frankly I don't understand what it is. If you put sudo -u my_user before bindfs in the script, then what exactly is the problem when you run the script as root or the user (with or without sudo)? – Kamil Maciorowski Jul 10 '21 at 18:30
  • your answer is correct (add sudo -u my_user to mount and umount commands). The problem with your answer is that it is a bash script that is run from root or with sudo ./script.sh so there is duplicate sudo – acgbox Jul 10 '21 at 18:45
  • Why is this a problem? sudo is the right tool to "change identity". If you need to change it twice then you need two sudos. – Kamil Maciorowski Jul 10 '21 at 18:48
  • If you claim that this is the right way (and that it is good practice), I suppose it is. Obviously I would not know if your answer is correct or not (that's why I asked the question. because I don't know the answer). Post it, for other users to review and confirm, then I will select it as the correct answer – acgbox Jul 10 '21 at 18:53
  • 1
    Possibly relevant: Should I use sudo in a script or sudo an entire script? I assumed you know what you want. If you really want to run sudo ./script.sh and then drop privileges inside the script then you need sudo or something similar in the script. – Kamil Maciorowski Jul 10 '21 at 18:57

1 Answers1

1

Instead of bindfs … use sudo -u my_user bindfs ….

If root runs the script then sudo should allow becoming my_user without password. If my_user runs the script then sudo should allow becoming the same user without password. If any user runs the script with sudo then it will be as if root run the script.

(Maybe some settings in sudoers can change this behavior regarding passwords. I don't know for sure. I expect the common sane configuration to behave as described though.)

My tests indicate root doesn't need sudo -u my_user before fusermount -u. However if another user simply runs the script (without sudo) and they are able to authenticate as my_user then they will be able to mount. For consistency it will be good to allow them to unmount in the same way, so sudo -u my_user before fusermount … may be a good thing.