Gentoo Archives: gentoo-user

From: Kai Krakow <hurikhan77@×××××.com>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: sans-dbus was: gnome intrusion?
Date: Sat, 19 Nov 2016 09:22:12
In Reply to: Re: [gentoo-user] Re: sans-dbus was: gnome intrusion? by Rich Freeman
1 Am Thu, 17 Nov 2016 04:08:31 -0500
2 schrieb Rich Freeman <rich0@g.o>:
4 > On Thu, Nov 17, 2016 at 2:56 AM, Ian Zimmerman <itz@×××××××.net>
5 > wrote:
6 > > On 2016-11-16 20:48, Rich Freeman wrote:
7 > >
8 > >> Policykit also lets you do stuff like saying this user is allowed
9 > >> to restart this service, but not do anything else, and so on,
10 > >> using a configuration which is flexible and works across different
11 > >> applications/etc.
12 > >
13 > > I'm curious what you mean by "service" here. Surely not the things
14 > > managed by rc-service, only root can touch them, right? Or regular
15 > > users via sudo, and then sudo config restricts what they can do.
16 > >
17 > > I'm _guessing_ you mean desktop services like gnome-settings, and my
18 > > retort is, I don't have any of those, and I never will.
19 > >
20 >
21 > No, I mean services as in stuff like apache, gnome, and so on.
22 > However, this was probably not a great example as it looks like none
23 > of the service managers actually support policykit for this right now,
24 > which means that only root can use these dbus commands.
26 I think systemd supports it, tho I don't know how granular that can be
27 made. Ideally, on a systemd machine, also desktop services are managed
28 by a user instance of systemd. In this case, the user is already able
29 to manage all these services. But most DEs still bring their own
30 service manager (like kded in KDE I think), managed through dbus with
31 an incompatible interface to systemd. The only systemd-native services
32 in my DE is currently pulseaudio, invaded by a few service brought by
33 Gnome components, including the aforementioned at-spi-dbus-bus.service
34 which I masked. Of course, dbus is part of this systemd user instance.
36 I've just taken another look at "systemctl --user status" and it looks
37 like more and more KDE services are also started from systemd now
38 through dbus activation. I wonder which components I could remove
39 from /etc/xdg/autostart so these are only started on demand through
40 dbus activation.
42 In the end, systemd /can/ make your system slimmer by starting services
43 (user and system) only on demand through dbus activation (or socket
44 activation).
46 > A better example might be doing things like changing the hostname,
47 > without being root, or start/stop a container/vm.
49 That's possible with policy-kit, tho I still think configuration
50 through XML is overly complex. A much simpler format could do, plus
51 make it actually human-readable.
53 > Sure, you can also do some of this using sudo, but sudo isn't actually
54 > a great tool for this as it is oriented around command line syntax,
55 > and not functional privileges. The whole point of something like
56 > dbus/policykit is that you define what you want somebody to be able to
57 > do, not what commands they can type in order to try to do it.
59 Using sudoers configuration is a huge security pita if you don't
60 exactly know what you do configure. Plus, it is quite cumbersome when
61 it comes to only parsing command lines for decision. Especially on a
62 server, I do not really feel comfortable with that.
64 > dbus support for these sorts of administrative functions is still
65 > somewhat limited, and I suspect it will remain so until it is
66 > completely merged into the kernel (or rather, bus1 is).
68 I think it's rather missing some good frontend utilities (GUI and CLI).
69 Especially combined with policy-kit.
71 > It is also
72 > somewhat new for these sorts of things. Previously it was more
73 > focused on desktop-like functionality, such as loading icc color
74 > profiles (apparently one of things you never will need).
76 Well, I think the "d" actually comes from "desktop". But with systemd
77 deployments, it also provides function for servers and their
78 management. I think, a lot can still be explored here. It's actually
79 useful. Tho, I'd also prefer a native kernel implementation with dbus
80 only sitting on top of it as a compatibility layer until all DEs
81 adapted it.
83 > Ultimately though the concept is a pretty sound one. There are lots
84 > of things done in userspace where you'd want the same kind of
85 > granularity that posix capabilities offer in kernel space, and
86 > policykit is a way to eventually manage these. UID=0 vs UID!=0 was
87 > once nice upon a time, but it isn't great for security, and the
88 > previous ways of addressing that tended to be lacking in various ways.
90 Well, let's wait for the argument "but this is not the unix way". ;-)
93 --
94 Regards,
95 Kai
97 Replies to list-only preferred.


Subject Author
[gentoo-user] Re: sans-dbus was: gnome intrusion? Ian Zimmerman <itz@×××××××.net>