set user id for service ?

[David Zeuthen]

On Fri, 2006-09-15 at 19:30 +0100, Scott James Remnant wrote:
> The iPod is probably mostly a bad example, which is what you get when
> other people write your use cases for you ;)  

Heh.

> 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.

Well, users can install what software they want and that's fine. My
personal view is that we shouldn't encourage people writing this kind of
software. 

> 
> Better examples are running services only when a network interface is
> up

NetworkManagerDispatcher? If that interface sucks then we should rather
fix NetworkManager than trying to work around it. I do understand that
NM will never work on servers, so, yeah, maybe this is OK to have in
upstart as you need it for early boot.

> , or running HPLIP only while an HP printer is connected, and so on.

Well, you should just use HAL callouts or addons or whatever since it's
hardware. HAL already contains a rich infrastructure doing just this,
see 

 http://people.freedesktop.org/~david/talks/dynamic-device-handling-OLS-2006.pdf

specifically page 13. I'm not sure why you'd want to use upstart for
this, the proper fix is make HPLIP integrate with HAL. Specifically, HAL
will pass things such as the address of the printer etc., can't see how
upstart would do that without heavily trying to duplicate what HAL is
doing. Do you think this is fair to say?

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

Then they get their own instance which is perfectly fine and expected.
So, user foo has some preference for LCD backlight, what drives to share
etc... user bar has others... 

the only things we need to fix is

 1. to refuse service for certain actions unless the user is on the
    active session (things like setting the LCD backlight, Suspend()
    when the user is idle). Of course, if the policy daemon itself 
    should know if the session is not active but we lack that
    infrastructure. 

    If upstart would provide a D-Bus interface with this kind of
    information (we'd need it for a lot of other things too)
    I'd be very thrilled. It's pretty hard to get right though,
    you'd need to listen to console switches and what-not.

 2. for multi-seat have a way for sessions to deny e.g. Suspend() calls
    from idle sessions. This is a bit tricky as to do this securely
    you need to know the caller wanting to deny is from a session. I'll
    put this in HAL soon regardless, it's not a huge deal and perhaps
    some day we can ask the X server if a given pid is connected to
    an X server to verify whether the caller is allowed to deny
    requests.

> 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.

Well, depends. I think perhaps having some central daemon like HAL
maintain a "all sessions idle" flag (idle if, and only if, all desktop
daemons have said they're idle) is a work around.

Doesn't change that we need 1. and 2. above regardless.. we badly need
to that kind of infrastructure on the free desktop. And if we start
doing things like centralized daemons it'll only take longer before we
get that. 

There's also the interesting issue of having both KDE and GNOME stuff
use the same centralized daemon. Good luck with that :-)

So that's why I'm opposed to it. (And, for the record, this argument
only rings true for power management - it's not applicable to network or
volume management.)

> > 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.

I'd much rather we just fix g-v-m to be able to run the script when
needed and use g-v-m when no-one is logged in.

For the users that need to run scripts when power events happen.. well..
ideally we'd fix g-p-m so they don't need it but reality is that some
do.. so g-p-m should provide a way to do that, and FWIW, I've already
filed that bug like six months ago

 http://bugzilla.gnome.org/show_bug.cgi?id=333031

There's a key difference here. I'm advocating, basically, use the
desktop daemon as the dispatcher for scripts or whatever. That way we
can provide the right UI for it. You are advocating "just have a generic
~/.event.d" directory and trouble the users to put scripts there. Sure,
you can build a generic gconf-editor / regedit style UI on top of that,
but that's really bad UI.

> > 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.

Well, that's something.

I still think it's utterly broken to have a different code base for
handling events. Especially because it means different features,
different bugs and different configuration. 

> 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 :)

Right. Just out of curiosity how does upstart help here? I mean, if I
have two seats each running g-p-m? This is not unlikely if the system
e.g. got a UPS.

As a conclusion, and apologies for being harsh, I think part of upstart
is trying to solve most of the problems we've already solved with HAL /
D-Bus / g-p-m / g-v-m / nm-applet... in a pretty bad way too.. that
leads to bad UI. And for what? Only to solve two things; 

 a. the pretty uninteresting case when no-one is logged in; and 

 b. to facilitate software written by people for whom root only exist. 

A bad side effect, should these features surface in upstart, is that it
will slow down getting the real bugs in the desktop software worked out.

I'm very thrilled about what upstart could be though. I think if you try
to stop duplicating what is already solved (would also make upstart much
simpler) and instead provide solutions to tracking user sessions (as
described above in bullet point 1.) then problem a. is solved. 

Sorry for being harsh.

Cheers,
David