Solved Running a rc.d script as another user

[borysj]

Hello, I am trying to set up a daemon for onedrive. It needs to be run as a specific user, because onedrive has to read the authentication token from the user home directory, and then synchronize into that directory.

However,

${onedrived_user="borysj"}

does not do the trick. I see that the script as such works, and onedrive works in itself, but if I try to start it through my daemon it cannot find the authentication token. I guess it looks for it in /root.

This is my script:

~ $more /usr/local/etc/rc.d/onedrived
#!/bin/sh

# PROVIDE: onedrived
# REQUIRE: DAEMON
# KEYWORD: nojail shutdown

. /etc/rc.subr

name="onedrived"
rcvar="onedrived_enable"

command="/usr/local/bin/onedrive"
start_precmd="${name}_prestart"
stop_postcmd="${name}_poststop"

onedrived_prestart()
{
        su borysj -c '/usr/local/bin/onedrive --synchronize'
}

onedrived_poststop()
{
        su borysj -c '/usr/local/bin/onedrive --synchronize'
}

load_rc_config $name
: ${onedrived_enable="YES"}
: ${onedrived_user="borysj"}
: ${onedrived_flags="--monitor"}
run_rc_command "$1"

What am I doing wrong? I read the article on Practical Rc.d Scripting, and I studied the manuals for rc.conf and rc.subr, but none of these resources pay much attention to running scripts as specific users.

And is my approach correct? I mean, should a daemon for a specific user be started through rc.d at all? But where else should I start it? If I do it through .zshrc, it will try to start every time I open a terminal window in X. If I do it through .xinitrc, it will not be active in console.

 

[covacat]

#!/bin/sh
#
# PROVIDE:
# REQUIRE:
# KEYWORD:
. /etc/rc.subr
PATH=${PATH}:/usr/local/sbin:/usr/local/bin

name="exampl"
rcvar=exampl_enable
load_rc_config ${name}

run_rc_command "$1"

in rc.conf
exampl_flags="-a"
exampl_program="/usr/bin/id"
exampl_user="man"

# /usr/local/etc/rc.d/exampl onestart
Starting exampl.
uid=9(man) gid=9(man) groups=9(man)

 

[borysj]

Thank you. However, it did not help. You have basically adviced me to move the parameters out of the script itself into the rc.conf, but it didn't make any difference.

However, I started to experiment with id to see how exactly the command is being run, and it was indeed run as by the user.

Then I have found the culprit: Even though the script was run as by a specific user, HOME was pointing to / (not even to /root). Quite surprising: Why does rc.conf offer the option to run a command as someone else if it doesn't care about that person's home directory?

I solved the problem by adding

HOME=/home/borysj

as the second line in the start precommand.

 

[covacat]

you use other user for privilege downgrade
but you can set env vars if needed with exampl_env or exampl_env_file (in rc.conf)
some programs do not look at $HOME they just lookup the user in /etc/passwd and find its $HOME
so the question is how much of a user env should rc scripts export ?
not even sudo exports $HOME by default in freebsd