set user id for service ?

[David Zeuthen]

Hi,

I'm adding Scott James Remnant (upstart developer) to the Cc list; we're
discussing whether and how the system bus daemon should do activation
and how that relates to upstart.

One reference, to give some context, is my mail here

 http://lists.freedesktop.org/archives/dbus/2006-September/005747.html

which basically states that 

 1. desktop apps needing to do privileged work should ask a D-Bus
    service to get that done (to avoid running them as root etc.); and

 2. D-Bus activation should be used to start the privileged helper
    and when the helper. When the helper is idle.. it may shut down

Assuming that's a good idea, the question is how this relates to upstart
which, I believe, is in the business of managing long running system
daemons and bringing up the OS.

Note that I'm not calling D-Bus activation on the system bus the
all-dancing, all singing tool. I would never propose to start
long-running services (like e.g. HAL or udevd) with it, only services
that will exist for the purpose of carrying out a single operation and
then exit.

On Fri, 2006-09-15 at 11:27 -0400, Havoc Pennington wrote:
> Here's a big macro question for you. Have you read the "upstart" docs? I 
> think to the extent dbus launches system daemons it overlaps with the 
> primary purpose of upstart, and to the extent upstart sends increasingly 
> complex events and works as an IPC system, it overlaps with the primary 
> purpose of dbus. 

Right. I'm slightly concerned too reading the upstart docs, two items
spring to mind. The first one is kinda off-topic for D-Bus list, but it
may say something about differences in where we're coming from...

>From https://wiki.ubuntu.com/ReplacementInit
> Orli owns an iPod and uses a popular piece of software to download
> podcasts onto it. He currently has to start the software when he
> plugs his iPod in, and remember to stop it afterwards. He would
> rather the system started and stopped the software automatically
> based on the presence of his iPod. (maybe edgy+1)

Not sure this is thought out. First of all g-v-m already does this, or
least it should. Second, you really want the desktop bits to trigger
this behavior as it needs to read the user's preferences. Third, for the
use case of doing this when Orli is not logged in, the idea is to run
desktop policy daemons (such as g-v-m, g-p-m, NetworkManager) when no
one is logged in (probably as user nobody) and terminate them when the
user logs in. 

(The thinking is 1) we reuse the existing code base; it's easy for the
user to configure what to do as they get a new button in the desktop
policy daemon system preferences called "set these settings as default"
that simply copies the gconf settings to the system default location
in /etc.)

(KDE-centric distributions would do similar)

So, upstart having that goal certainly frightens me a bit - I mean,
you'd need to reinvent a lot of wheels to do this for example how do you
detect that it's an iPod that is inserted etc. etc. 

I also think, as noble as the goal may be to help Orli by allowing him
to drop a custom written script somewhere (that does things when the
magic mount point /media/ipod is available) dilutes the mission that
some of us are trying to achieve - e.g. move all relevant desktop policy
to the desktop session... because that's where it belongs. I'm saying,
if it's not easy to put an UI to policy or settings, it's broken.

So.. In my view it's much better to patch g-v-m if it doesn't do what
you want already. But, that's more of a philosophical question -
personally I think the UNIX way of doing things is bullocks and it seems
to me upstart is compatible with that view - e.g. replacing the cruft
that is SysVInit.
 
Btw, if upstart can help in any way with achieving the goal of
starting / stopping desktop policy daemons when no one is logged in I'd
be very interested to hear about it. That would actually be great! Is
there a chance this is within the scope of upstart?

(Btw, the problem is more difficult than I've outlined, it should
probably be designed to cover weird edge cases such as multi-seat (Q: do
you run a copy of g-p-m on every console? A: probably) though we need
not implement this as early.)

There's also this bit on the Wiki when asked why D-Bus is not used
> "to d-bus people, everything looks like a d-bus problem" 

which is not really a good answer. Sure, there's been a lot of hype
around D-Bus, I'd and probably Havoc too are the first to admit that,
but, really... why invent your own IPC system? 

Btw, for the record, in Fedora we install libdbus in /lib so it's
available right when rootfs is mounted. I understand you want to cut
dependencies where at all possible, but... it's 2006 already and D-Bus
is pretty close to a 1.0 release. 

I see two potential responses here

 1. "It's easier to audit the code". 

    This doesn't make sense to me, I mean, we're all pretty screwed if
    D-Bus is vulnerable anyway. And we could certainly use more eyes
    looking at the D-Bus source etc.

 2. "Need other things started before starting the system message bus."

    Pretty sure this only includes the rootfs and special file systems
    such as /proc, /dev, /sys or whatever. 

    Personally I think doing this should just be hard-coded but some
    people don't think this as they want a super customizable system
    where they can choose not to use e.g. udev or mount /sys. 

    That's in my view a bit flawed but I do understand that some
    embedded systems are like this and some distributions have users who
    would be upset if those kind of options were not available. I'd say,
    just special case this part of upstart to not have IPC or whatever.

Anyway, upstart using it's own IPC is not the biggest of my concerns, I
just wouldn't have made that trade-off myself. But we're all different
and that's fine. 

Havoc also wrote:
> I have some fear that the result is a big mess where 
> any given task can be done with either upstart or dbus, or worse 
> distributions diverging on this point.

Right. The important thing here is scope. We need to present developers
with an easy to understand stack of software and it should be clear to
them when to use D-Bus activation on the system bus (my view: small
privileged helpers used from time to other) and when to use things like
upstart (my view: long-running daemons). What do you think?

So.. let's see what Scott has to say about that. I'm hopeful there will
be little overlap in scope, that's certainly something that would make
me a lot more interested in looking at upstart for e.g. Fedora. I'd hate
to see wheels reinvented... just because we suck at talking to each
other in the free source world. 

This mail is trying to make us talk.

(hope none of the things above come across as flames - I personally
think Upstart is an interesting effort, not only because it replaces old
braindead UNIX cruft, but because it provides a lot of needed features
that we need for managing long-running daemons. I'd very much like to
see this in e.g. Fedora one day.. when I better understand it's scope.)

Thanks,
David