Running service as a user

Asked by Eoghan Gaffney on 2008-09-22

Is it possible to run an upstart service as another user? Similar to how cron can specify which user a job runs as. If not directly, is there a workaround?

Question information

English Edit question
upstart Edit question
No assignee Edit question
Last query:
Last reply:
aberlanas (angel-berlanas) said : #1

This is usefull for you?
exec su myuser -c "exec mydaemon"

Igor Galić (i.galic) said : #2

If I wanted to start an httpd to only run with the minimum capabilities(7) needed, that's not possible with su or sudo.
The trouble those is that they don't respect pam_cap (or PAM in general), when executed as a privileged user:

[root@prvix]/etc# grep auth pam.d/system-auth
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required debug
auth required
auth sufficient try_first_pass nullok
auth required
[root@prvix]/etc# cat security/capability.conf
cap_net_bind_service daemon
cap_net_bind_service i.galic
none *
[root@prvix]/etc# getent passwd daemon
[root@prvix]/etc# getent passwd i.galic
i.galic:x:500:500:Igor Galić:/home/i.galic:/bin/zsh
[root@prvix]/etc# sudo -u daemon getpcaps $$
Capabilities for `22898': =ep
[root@prvix]/etc# sudo -u i.galic getpcaps $$
Capabilities for `22898': =ep
[root@prvix]/etc# su - i.galic
i.galic@prvix ~ % getpcaps $$
Capabilities for `12303': =
i.galic@prvix ~ % su - i.galic
i.galic@prvix ~ % getpcaps $$
Capabilities for `12353': = cap_net_bind_service+i
i.galic@prvix ~ % and /etc/security/capability.conf would be a very simple way to implement capabilities in upstart, since it would mean to outsource this to an existing Unix tool chain and one would ``only'' have to register an authentication facility for upstart with PAM. (As a side note: Solaris' SMF (Service Management Facility) offers the ability to start services with a reduced set of privileges(5) - but they implement this from scratch.)

Am I making sense here? Is this anywhere in the scope of upstart? Could it be?

Randall Leeds (randall-leeds) said : #3

If I understand the issue correctly, I just addressed something similar myself.
The solution is to have libcap2-bin add the as optional before the root user su in /etc/pam.d/su

My file used to show:

# This allows root to su without passwords (normal operation)
auth sufficient

I changed it to:
# This allows root to su without passwords (normal operation)
auth optional
auth sufficient

By default, libcap2-bin only installs the pam_cap module in /etc/pam.d/common-auth, which is only included below these lines. Therefore, changing users with su from root ignores the pam_cap module and misses /etc/security/capability.conf.

In my /etc/security/capability.conf I have:

cap_net_bind_service couchdb

And finally, add the capability to your service's binary or interpreter. Setting the capability to "effective and permitted" (+ep) is an EXTREMELY BAD IDEA, especially with an interpreter (a service run with python or erlang must set capabilities on the interpreter binary), since all users will get this permission. However, using "effective and inherited" only works a charm to propogate the rules from /etc/security/capability.conf only to the user/program combination you need.

In my case, this meant executing the following:

$ setcap cap_net_service_bind=+ei /usr/lib/erlang/erts-5.8.4/bin/beam.smp

Can you help with this problem?

Provide an answer of your own, or ask Eoghan Gaffney for more information if necessary.

To post a message you must log in.