Restarts initiated by non-root users

19 views
Skip to first unread message

Carl Youngblood

unread,
Jan 11, 2010, 9:23:28 AM1/11/10
to Bluepill
I want to set up a post-build trigger that restarts a service that is
being monitored by bluepill. The bamboo remote agent that runs this
post-build trigger is not running as root. What do you think is the
best way to have this post-build trigger tell bluepill that it wants
the service to be restarted?

Thanks,
Carl

Carl Youngblood

unread,
Jan 11, 2010, 9:32:34 AM1/11/10
to Bluepill
For the moment, I set this up to use sudo to run bluepill and disable
password prompts for sudo users. If anyone has a better idea, let me
know.

Arya Asemanfar

unread,
Jan 13, 2010, 7:36:58 PM1/13/10
to bluep...@googlegroups.com
We have plans to support of not-requiring root to run the bluepill daemon, which would only work if all the processes were run by the same user. So you couldn't have 5 different processes all running as different users.

There are three other ways that I know of that will allow non-root users to act on bluepill:

1. We can do something similar to what Passenger does for restarting processes which is watch for a file. You can achieve this by having a process condition that checks for a file in some specified location every x seconds, if the file exists remove the file and restart the process. This is a simple way to do it but doesn't give much flexibility or control.

2. Another thing we can do is create several socket files instead of just one. We can have one sock file accessible by each user who has a process running for them and that sock file only allows commands executed on processes owned by that user. This would mean N + 1 socket files where N = the number of unique users that have processes running through bluepill.

3. Lastly, we can simply make the socket file world writeable which means anyone can issue bluepill commands (except for load). The processes themselves would still run as the specified user but could be start/stop/restarted by any user who has access to the machine.

Please share your thoughts on these approaches.

-Arya

Carl Youngblood

unread,
Jan 14, 2010, 6:50:59 AM1/14/10
to bluep...@googlegroups.com
Glad to see you're thinking about these. I don't think I have a lot to
add to the considerations you've already made, but here are some
thoughts:

1) The passenger approach seems like a nice feature that should be
easy to implement. It might be worth adding as a short-term fix.

2) Sockets for each user seems like a good long-term approach,
although more complex to implement.

3) I think that the security implications of allowing commands from
any user makes this approach not worth it.

Reply all
Reply to author
Forward
0 new messages