set user id for service ?

[Scott James Remnant]

On Fri, 2006-09-15 at 13:06 -0400, David Zeuthen wrote:

> 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 iPod is probably mostly a bad example, which is what you get when
other people write your use cases for you ;)  Most of the things you'd
want to do with an iPod are likely to be handled from the desktop and a
user's session.

The only time this happens to be relevant is when you're dealing with a
podcastd daemon that is written by someone who thinks as root, so it's
run as an ordinary UNIX service, etc.

Better examples are running services only when a network interface is
up, or running HPLIP only while an HP printer is connected, and so on.


The "desktop policy daemon" idea doesn't seem well thought out to me,
what happens if two users log in?

It makes more sense that the control daemon would be running at all
times while the hardware is connected, and users sessions would dial in
and communicate to _that_ daemon rather than running a different
instance of their owns.

> 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.
> 
That's a goal of upstart as well... right now the user would have to put
their iPod script in one place, and their network script in another, and
their "power going away" in other.  upstart moves them all to ~/.event.d
or similar.

> 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.
> 
Agreed.
 
> 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?
> 
This, in my view, _was_ the scope of upstart ;)  upstart would start the
daemon that runs all the time, whether a user is logged in or not, and
then users would use that daemon.

If one is totally set on the idea of "killing the root daemon" (which is
utterly broken for multiple users <g>) then one can use upstart for that
too:

	start on startup
	stop on user-logged-in

Type thing.

> (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.)
> 
Remember that one of Ubuntu's derivatives is designed around a
multi-seat and thin-client system -- so we very much like to think of
these things today :)

> 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? 
> 
That was in response to why not use dbus /service activation/ as the
basis for an init; which is wrong for many reasons.

As for the own IPC system, the answer is simply that dbus isn't yet
stable enough or ubiquitous enough to be a dependency of the one process
that causes the kernel to PANIC! if it goes away <g>

The principal blockers are:

 - stable protocol, API, ABI, etc.

 - dbus daemon must be able to be restarted without losing client
   connections  (upgrade dbus and be unable to tell your machine to
   reboot?  OOPS! :p)

 - dbus daemon must end in in /, not /usr  (probably going to happen
   eventually, but isn't yet true on Ubuntu)

I think I say in that answer that it makes sense to use dbus eventually,
just that it's not yet suitable.

The IPC is pretty simple currently, and not intended to be too complex.

> 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. 
> 
Agree entirely :)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060915/08c0c158/attachment-0001.pgp