2

I'm making an upstart job, and I need to run an executable as another user. Nothing fancy like su provides, and none of the mixed-up SELinux contexts that come along with it. A quick internet search recommends runuser over su for this task, but runuser is nowhere to be found on Ubuntu 13.10.

Should I be using su on Ubuntu--will it be smart enough to avoid full authorization? Would a resulting job be portable to other distros, or will I run into SELinux issues?

Ultimately, what's the best way to change users in an upstart job?

Update

Apparently upstart >= 1.4 supports setuid and setgid, but they're limited in that they affect all of the job pre-*/post-* scripts, not just the primary script/exec. It'd still be nice to have a way to properly drop to another user for a single command. I've considered using stop-start-daemon, but it overlaps too much with upstart and will likely cause expect to behave oddly.

2
  • I think this link may help you serverfault.com/questions/518713/… Nov 23, 2013 at 5:03
  • @AvinashRaj I saw that, but the user's question is never properly answered. I know how to use su and sudo--I also know that they're not meant for what I'm doing.
    – Zenexer
    Nov 23, 2013 at 5:56

1 Answer 1

2

There is a bug report regarding this problem.

Suggested work around the the limitation is to create a separate jobs to handle the pre/post conditions whilst running as root. You would need to correctly setup start/stop conditions: Job emulating pre stanza (pre-job.conf) would have to start on conditions defined currently for your job (main-job.conf), your current job will have to run on pre-job started, job emulating post stanza (post-job.conf) will have to start on main-job stopped.

1
  • Not quite what I expected, but seems to do the trick, and it's not too hackish--probably better than runuser/su.
    – Zenexer
    Dec 19, 2013 at 7:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .