set user id for service ?

[Scott James Remnant]

On Tue, 2006-09-19 at 21:39 -0400, David Zeuthen wrote:

> On Wed, 2006-09-20 at 01:46 +0100, Scott James Remnant wrote:
> > On Tue, 2006-09-19 at 15:43 -0400, David Zeuthen wrote:
> > 
> > > On Sat, 2006-09-16 at 01:48 +0100, Scott James Remnant wrote:
> > > > GNOME Power Manager is an example of something that does one thing,
> > > > dealing with power management, and does it well.
> > > 
> > > One question: how can you trust the events that g-p-m would send to
> > > upstart are genuine? Ie. how do you ensure that they don't come from a
> > > malicous attacker? Seems like you can't do this securely...
> > > 
> > If an malicious attacker has root, you already have bigger problems.
> > One of the reasons upstart has its own IPC is so that it can obtain the
> > pid and, more importantly, uid of the process sending the message.
> > 
> > It never runs anything the requester doesn't have permission,
> > themselves, to run.
> 
> So, if I'm running a normal desktop session and AC is unplugged, then
> g-p-m, running as uid 500, will poke the upstart daemon. Fine. The admin
> have written an upstart rule to do stuff and that gets invoked. Will
> that be invoked as uid 500? That wouldn't be very useful for the admin.
> 
No, it wouldn't be invoked at all -- but then I wouldn't recommend g-p-m
poke upstart directly using its own IPC.  I would suggest instead that
g-p-m just use dbus messages, and have a dbus security policy specified
to allow delivery to upstart.

Why reinvent security wheels at this point, dbus has the smarts we need
for this already.

> > >  http://bugzilla.gnome.org/show_bug.cgi?id=333031
> > > 
> > > for g-p-m to run user scripts when significant events happen.
> > > 
> > I would say that this is an excellent example of where upstart slots in.
> > 
> > Why do we need yet _another_ *.d directory, with yet more semantics
> > about how it works?
> > 
> > Why does yet another daemon need to gain the ability to iterate scripts,
> > with yet more naming semantics (ie. ignoring *.dpkg-old) and having the
> > same bugs that others do, such as leaking file descriptors, not killing
> > or reaping the process correctly, and so on.
> > 
> > g-p-m should arrange for upstart to be notified of the event, probably
> > just through the dbus messages that announce these changes, and let the
> > dedicated service/task manager process take care of running the scripts.
> 
> It, of course, make sense to just make upstart handle this.
> 
> Alternatively, it would be useful with either 1) a library; or 2)
> service in the session; that things like g-p-m could use to do this.
> g_spawn() isn't too terrible but I hate to see each policy daemon
> rolling their own including addressing all the concerns you list above. 
> 
Yeah, it could be a library or service in the session.  It's far easier
just to make init more useful in this regard so you don't need either.
Especially seeing as init has to do all this kind of work already, to
keep dbus, HAL and X running in the first place ;)

> For integrating g-p-m with upstart.. instead of patching g-p-m... you
> can listen to events on the session message bus... meaning you need
> something running in the desktop session to poke upstart.
> 
The messages would need to reach the system bus, but does this not
happen already?  "Battery Power Critical" seems like a system message to
me, not a user session one?

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/20060920/a74626a1/attachment.pgp