1 |
Am Thu, 17 Nov 2016 04:08:31 -0500 |
2 |
schrieb Rich Freeman <rich0@g.o>: |
3 |
|
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. |
25 |
|
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. |
35 |
|
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. |
41 |
|
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). |
45 |
|
46 |
> A better example might be doing things like changing the hostname, |
47 |
> without being root, or start/stop a container/vm. |
48 |
|
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. |
52 |
|
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. |
58 |
|
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. |
63 |
|
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). |
67 |
|
68 |
I think it's rather missing some good frontend utilities (GUI and CLI). |
69 |
Especially combined with policy-kit. |
70 |
|
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). |
75 |
|
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. |
82 |
|
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. |
89 |
|
90 |
Well, let's wait for the argument "but this is not the unix way". ;-) |
91 |
|
92 |
|
93 |
-- |
94 |
Regards, |
95 |
Kai |
96 |
|
97 |
Replies to list-only preferred. |