Running service as a user

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

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
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_cap.so debug
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass nullok
auth required pam_deny.so
[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
daemon:x:2:2:daemon:/sbin:/sbin/nologin
[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
Password:
i.galic@prvix ~ % getpcaps $$
Capabilities for `12353': = cap_net_bind_service+i
i.galic@prvix ~ %

pam_cap.so 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?

If I understand the issue correctly, I just addressed something similar myself.
The solution is to have libcap2-bin add the pam_cap.so 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 pam_rootok.so

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

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