On Tue, 2007-03-20 at 21:41 -0400, Matthew Miller wrote:
> On Tue, Mar 20, 2007 at 09:24:05PM -0400, David Zeuthen wrote:
> > FWIW, this is something we sorely need in a modern system + all this is
> > not restricted to HAL at all; it's about having a formal way of
> > classifying what a user (uid) / group (gid) / program (security context)
> > is allowed to do and not to do. Think about parental controls for
> > example. So as this is applicable to many other things where we today do
> > broken stuff like running X11 applications as uid 0 - and that pretty
> > much includes everything in the System->Administration menu. It's just
> > broken by design.
>
> I'm very much looking forward to seeing what you're currently thinking about
> all this. It'd be really nice if we could replace usermode/consolehelper
> with something more sane.
It's pretty brutal what I want to do since it involves rewriting bunch
of stuff which in some circles is extremely unpopular. I've also been
called naive. I'm also sure I'll get flamed and called names but anyway
here goes...
Basically, I'm saying that if an application needs to do privileged
operations it needs to use a helper. This can either be a setuid helper
(bad, but not necessarily) or a daemon can be poked via IPC. That IPC
could be D-Bus. With D-Bus system bus activation this is really simple,
basically this feature lets you define a service
$ cat /usr/share/dbus-1/system-services/dk.fubar.Test.service
[D-BUS Service]
Name=dk.fubar.Test
Exec=/home/davidz/Hacking/activation-test-service/test-service.py
User=0
and as soon as someone (e.g. a desktop app) calls into dk.fubar.Test on
the system message bus, the system message bus daemon will "activate"
that service, e.g. it will spawn $Exec as $User, $Exec will acquire the
name on the bus and then the bus passes the method call into the owner.
It's totally transparent to the caller (e.g. the desktop app) whether
that the service dk.fubar.Test exists already.
This is actually extremely useful; consider the GNOME clock applet. It
will simply just ship with a small helper and a file it puts
in /usr/share/dbus-1/system-services. Then when you want to change the
timezone / time / date etc. the clock applet simply does this D-Bus call
org.gnome.ClockApplet.SetTimeZone("Europe/Copenhagen") on the system
bus.
Since no-one owns the name org.gnome.ClockApplet, the service for doing
this is activated (call it /usr/libexec/gnome-applet-set-time), it
changes the time zone and returns. After 30 secs of inactivity, or
whatever, gnome-applet-set-time decides to kill itself to save system
resources. If it's needed again, it will be activated again. This is
really nice. It allows upstream projects, like GNOME and KDE, to
actually make some of the applets useful with very few lines of code.
Ideally, too, common things like D-Bus services for setting the timezone
etc. can be shared via a fd.o project. It's kinda similar to
gnome-system-tools... in spirit at least.
Anyway, for this to be secure, the helper itself (whether it's setuid or
activated via D-Bus) of course needs to determine whether it should
carry out the request from the caller. This is where PolicyKit comes in;
it's basically just a mechanism to make it easy to define who/what can
do a certain operation. This is a bit complicated and abstract; I think
basically PolicyKit will just become a small library interface that e.g.
org.gnome.ClockApplet can use but with pluggable backends. By default it
would use a file based backend but it should be possible to replace it
with other checks; e.g. fetch the policy from a LDAP server or whatever.
Oh, then there's the bit where the PolicyKit library says "user is not
privileged to do XYZ". For this, the helper just throws a well-known
exception via D-Bus and the user app knows it's denied because of
PolicyKit. Depending on what XYZ is the admin may have configured that
any user can do XYZ (such as mounting internal drives) if they auth as
root. The thinking here is that the user can do this auth with the
PolicyKit daemon; this leaves a small file somewhere in,
say, /var/lib/PolicyKit, that the PolicyKit library will pick up and the
next time the desktop calls into the helper to do XYZ it will succeed.
That's party explained in
http://webcvs.freedesktop.org/hal/PolicyKit/doc/spec/polkit-arch.png?revision=1.1
... this scary diagram! It's actually pretty simple. Keep in mind this
is a year old.
Hmm.. it's still a bit complicated; that's why I was so hesitant to
finish it. But I think _something_ like this is the way of the future,
I'm just afraid to have too many moving parts and points of failure... I
have to think a bit more about it.
Coming back to the big dreaded rewrite, I don't think people should be
too afraid; I'd imagine that things like yum could easily use this and
provide UpdateSystem(), InstallPackage(), ReconfigureRepos() method
calls so we don't need to run things like pup or pirut X11 apps as root.
They would just activate a yum D-Bus service that carried out the work.
Heck, it would help with these annoying flashes because these X11 apps
are not multi-threaded; it would also help with the lock contention
caused by yum-updatesd....
Anyway, hope this clarifies...
David
ps. will not respond to flames :-)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
