Udev rules, run as non-root

TuxForLife · 2015-12-23 00:56:50

Hello there, back when I had Linux Mint, when I plugged a USB drive in, it is automatically mounted, and the file manager automatically opened as the logged in user (eric).

I would love to do something similar, I have all the rules running perfectly however, here is my problem:
I don't know how to do this through the currently logged in user, I can only do it as the superuser.

Thanks guys, I hope you can lend me your 2 cents.

jasonwryan · 2015-12-23 00:59:26

systemd.wants and a service file...

See man systemd.device

tom.ty89 · 2015-12-23 01:21:35

Udev rules?

To me, all the behaviour you mentioned sounds just to be something that is provided by a gvfs-backed file manager. For example pcmanfm here works exactly the same way as you said, without any kind of udev rules.

TuxForLife · 2015-12-23 01:34:39

Jason, do you have a gist of how I should be doing it? I wasn't able to figure it out.

Tom, I do have pcmanfm, and it may work in that scenario, but I was thinking of doing more than just opening the file manager, I just would really like to run the rule as "eric" instead of root

jasonwryan · 2015-12-23 01:42:01

This is how I did it: http://jasonwryan.com/blog/2014/01/20/udev/

tom.ty89 · 2015-12-23 01:47:12

I have no idea on what you're talking about tbh. Udev rules is mostly used to control how your hardware behave. Although it can be used to run certain command when there are changes in the hardware, I don't feel like what you're thinking should be the job of udev.

In any case, do you have some concrete examples of udev rules that you want to "run as normal user"?

tom.ty89 · 2015-12-23 01:55:45

jasonwryan wrote:

This is how I did it: http://jasonwryan.com/blog/2014/01/20/udev/

SUBSYSTEMS=="usb", ATTRS{idProduct}=="1905", ACTION=="add", ENV{SYSTEMD_WANTS}=="upmusic.service"

Should it actually be ENV{SYSTEMD_WANTS}+="upmusic.service" instead of ENV{SYSTEMD_WANTS}=="upmusic.service"? Otherwise it would only be a no-op?

I don't get why you would enable the service either. Isn't it supposed to be started by the rule instead of started right after boot? Oh nvm it's because it's wanted by the mount unit. But then what does the rule do?

Last edited by tom.ty89 (2015-12-23 02:22:20)

jasonwryan · 2015-12-23 03:02:01

The rule triggers the script (upmusic.service) that rsyncs the music library to the mounted drive.

TuxForLife · 2015-12-23 03:10:47

Tom:
Here is my rule (that works great as root)
RUN+="/usr/bin/pcmanfm /home/eric/my/script"

This opens pcmanfm in a root window, it is rather noticeable since it opens up in a different theme.
One problem that occurs when running as root is that my script contains ~, and it is read as "root/" rather than "/home/eric".
I'm writing this script for my mom, and I don't want to give her sudo permission!

Jason, I think it's very awesome you sent me a link that you personally are hosting yourself.
After reading all of it carefully, I'm not too sure there will be a difference. Your methods seems to benefit when running long scripts, but I read no indication of what user to run it as.
Please let me know if I'm wrong, and I'll give it a go immediately.

jasonwryan · 2015-12-23 03:16:08

The whole point of triggering a systemd service is that it allows you to assign environment variables, like who the user is...

tom.ty89 · 2015-12-23 05:52:10

jasonwryan wrote:

The rule triggers the script (upmusic.service) that rsyncs the music library to the mounted drive.

Isn't the service triggered media-Apollo.mount? and media-Apollo.mount is triggered by udiskie.

And judging by your original udev rule on the blog (which has 4 matches but with no action at all), I bet you simply thought you need the rule but the fact is you do not.

Last edited by tom.ty89 (2015-12-23 05:53:12)

TuxForLife · 2015-12-23 05:57:41

Hey gentlemen, thanks a lot for your 2 cents.

I was able to get it working with the painfully simple adjustments:
ATTRS{vendor}=="0x8086", ATTR{size}=="15632384", ENV{DISPLAY}=":0", ENV{HOME}="/home/eric", RUN+="/home/eric/scripts/MCE/MCE-NewListing"

Thank you, have a fun holiday weekend

jasonwryan · 2015-12-23 06:00:31

Yes, Fred made the same point in the comments.

tom.ty89 · 2015-12-23 06:03:11

TuxForLife wrote:

Tom:
Here is my rule (that works great as root)
RUN+="/usr/bin/pcmanfm /home/eric/my/script"
This opens pcmanfm in a root window, it is rather noticeable since it opens up in a different theme.
One problem that occurs when running as root is that my script contains ~, and it is read as "root/" rather than "/home/eric".
I'm writing this script for my mom, and I don't want to give her sudo permission!
Jason, I think it's very awesome you sent me a link that you personally are hosting yourself.
After reading all of it carefully, I'm not too sure there will be a difference. Your methods seems to benefit when running long scripts, but I read no indication of what user to run it as.
Please let me know if I'm wrong, and I'll give it a go immediately.

I wonder why/how you run a script with a file manager, but nvm.

Although I think jasonwryan has some mis-thought in his solution, that I don't think his solution actually needs to involve a udev rule, I agree with him that systemd (user) units is the appropriate way to do it.

Since you brought up about sudo, you should know that sudo does means root permission. You can use sudo to run things as certain normal user. If the job isn't too fancy, sudo might be a solution as well.

TuxForLife · 2015-12-23 06:13:04

The file manager was more of an example behavior from my past experience that may relate to others.
Linux Mint opened the file manager as the logged in user, not root, which was the behavior I was looking for.

However, yes part of my script uses a file manager, and it was the giveaway that it was running the script as root.

Sorry for the confusion!

tom.ty89 · 2015-12-23 06:23:43

TuxForLife wrote:

ATTRS{vendor}=="0x8086", ATTR{size}=="15632384", ENV{DISPLAY}=":0", ENV{HOME}="/home/eric", RUN+="/home/eric/scripts/MCE/MCE-NewListing"

FWIW this does not equal to run as non-root. It's simply root with two extra env vars. In case the script creates some file or so, the ownership will still be root.

TuxForLife · 2015-12-23 07:55:06

You're absolutely right, I wasn't able to figure it out.
My current workaround is just running `chown -R eric:eric ./**`
But if you or anyone else thinks of something better feel free to share

tom.ty89 · 2015-12-26 02:46:30

Well as we've suggested, either use systemd (user) unit(s), or something like `sudo -u eric /home/eric/scripts/MCE/MCE-NewListing`.

snakeroot · 2015-12-26 15:44:31

Why don't you just run udiskie as a systemd user service?

Arch Linux

#1 2015-12-23 00:56:50

Udev rules, run as non-root

#2 2015-12-23 00:59:26

Re: Udev rules, run as non-root

#3 2015-12-23 01:21:35

Re: Udev rules, run as non-root

#4 2015-12-23 01:34:39

Re: Udev rules, run as non-root

#5 2015-12-23 01:42:01

Re: Udev rules, run as non-root

#6 2015-12-23 01:47:12

Re: Udev rules, run as non-root

#7 2015-12-23 01:55:45

Re: Udev rules, run as non-root

#8 2015-12-23 03:02:01

Re: Udev rules, run as non-root

#9 2015-12-23 03:10:47

Re: Udev rules, run as non-root

#10 2015-12-23 03:16:08

Re: Udev rules, run as non-root

#11 2015-12-23 05:52:10

Re: Udev rules, run as non-root

#12 2015-12-23 05:57:41

Re: Udev rules, run as non-root

#13 2015-12-23 06:00:31

Re: Udev rules, run as non-root

#14 2015-12-23 06:03:11

Re: Udev rules, run as non-root

#15 2015-12-23 06:13:04

Re: Udev rules, run as non-root

#16 2015-12-23 06:23:43

Re: Udev rules, run as non-root

#17 2015-12-23 07:55:06

Re: Udev rules, run as non-root

#18 2015-12-26 02:46:30

Re: Udev rules, run as non-root

#19 2015-12-26 15:44:31

Re: Udev rules, run as non-root

Board footer