| 1 |
On Thu, Nov 17, 2016 at 2:56 AM, Ian Zimmerman <itz@×××××××.net> wrote: |
| 2 |
> On 2016-11-16 20:48, Rich Freeman wrote: |
| 3 |
> |
| 4 |
>> Policykit also lets you do stuff like saying this user is allowed to |
| 5 |
>> restart this service, but not do anything else, and so on, using a |
| 6 |
>> configuration which is flexible and works across different |
| 7 |
>> applications/etc. |
| 8 |
> |
| 9 |
> I'm curious what you mean by "service" here. Surely not the things |
| 10 |
> managed by rc-service, only root can touch them, right? Or regular |
| 11 |
> users via sudo, and then sudo config restricts what they can do. |
| 12 |
> |
| 13 |
> I'm _guessing_ you mean desktop services like gnome-settings, and my |
| 14 |
> retort is, I don't have any of those, and I never will. |
| 15 |
> |
| 16 |
|
| 17 |
No, I mean services as in stuff like apache, gnome, and so on. |
| 18 |
However, this was probably not a great example as it looks like none |
| 19 |
of the service managers actually support policykit for this right now, |
| 20 |
which means that only root can use these dbus commands. |
| 21 |
|
| 22 |
A better example might be doing things like changing the hostname, |
| 23 |
without being root, or start/stop a container/vm. |
| 24 |
|
| 25 |
Sure, you can also do some of this using sudo, but sudo isn't actually |
| 26 |
a great tool for this as it is oriented around command line syntax, |
| 27 |
and not functional privileges. The whole point of something like |
| 28 |
dbus/policykit is that you define what you want somebody to be able to |
| 29 |
do, not what commands they can type in order to try to do it. |
| 30 |
|
| 31 |
dbus support for these sorts of administrative functions is still |
| 32 |
somewhat limited, and I suspect it will remain so until it is |
| 33 |
completely merged into the kernel (or rather, bus1 is). It is also |
| 34 |
somewhat new for these sorts of things. Previously it was more |
| 35 |
focused on desktop-like functionality, such as loading icc color |
| 36 |
profiles (apparently one of things you never will need). |
| 37 |
|
| 38 |
Ultimately though the concept is a pretty sound one. There are lots |
| 39 |
of things done in userspace where you'd want the same kind of |
| 40 |
granularity that posix capabilities offer in kernel space, and |
| 41 |
policykit is a way to eventually manage these. UID=0 vs UID!=0 was |
| 42 |
once nice upon a time, but it isn't great for security, and the |
| 43 |
previous ways of addressing that tended to be lacking in various ways. |
| 44 |
|
| 45 |
-- |
| 46 |
Rich |
Archives