set user id for service ?

[Srećko Morović]

On Wed, 20 Sep 2006 at 03:43 +100, Scott James Remnant wrote:
>> FWIW, I even convinced my colleague Dan Williams (NM author and primary
>> maintainer) that NM is broken in this regard and that we should fix it.
>> The bits doing the heavy lifting will be implemented as method calls on
>> HAL device objects. Then all policy etc. can be moved to a simple easy
>> to understand single-threaded daemon instead of the current mess we have
>> today with two daemons connected by an IPC pipe. It's just a lot of work
>> and neither Dan nor I have the time to do this right now as we're busy
>> with other things.
>>
>So HAL would get the ability to make changes to hardware, and thus in
>effect just becomes the central daemon itself?


It seems so, and it is basically how e.g.  g-p/v-m programs already work. As
far as I understood, those managers do user-level actions themselves.
Actions that need root priviledge are forwarded to HAL which then should
decide to accept it or not (based on the policy setting). Then HAL forwards
commands to it's addons or changes hardware setting itself. It makes sense
to do so, manage all hardware related settings and security policy for
machine in one place, instead of putting another policy in a special
d-bus<->upstart proxy configuration, network manager, or in /etc/event.d
files.

Of course I understand that scope of upstart is wider than only hardware
control (HAL scope) so other root-owned policies for determining who is
allowed to run which script(or events) should also exist for general cases (
e.g. permission to start a specific realtime process by uid/group,
start/stop sharing user's public_html although spache script might require
root privs etc.) but I'd leave hardware stuff to HAL as it contains most
information and abstraction levels about various hardware.

Idea that I liked is that HAL could use upstart to launch it's addons or
general scripts/dynamic services. That way same event can be used to launch
those even without HAL like if users wants to have a "fixed" startup. For
example if I want to manually start/stop network services (the old way)
instead when future hal-based NM decides the hardware is plugged in, I just
run simple command to issue that event.

Regarding mentioned battery example, if for example battery is critical it
is a system thing which HAL takes care about, but maybe user could be asked
whether to hibernate or given opportunity to save files and power off (of
course with fallback timeout if user isn't there, set in HAL settings). This
is where UI-integrated managers jump in, they receive dbus notification from
HAL and return the user's answer to it while also apply his configuration
choices like whether he checked "do this always" box (and eventually run
some user-related tasks like saving documents etc.).

I agree also that tools like g-p-m though could/should some day use upstart
for spawning services, even tasks with user priviledges instead of using
their own implementation for control of it. Configuration frontend could
even be written which creates and manages resulting files in ~/init.d/ - for
those who still want to use gconf or various desktop-dependent tools for
simple task creation, or convert old scripts. And even upstart could have
backends for putting (some?) event.d/ files in various places and forms.


Just my 2 cents,

Regards,
Srecko Morovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/upstart-devel/attachments/20060920/d3616592/attachment.htm