From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 176C61395E2 for ; Sat, 19 Nov 2016 09:22:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C3FF7E0C25; Sat, 19 Nov 2016 09:22:05 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 645D5E0C1F for ; Sat, 19 Nov 2016 09:22:05 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1c81qN-0008JJ-AG for gentoo-user@lists.gentoo.org; Sat, 19 Nov 2016 10:21:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Kai Krakow Subject: [gentoo-user] Re: sans-dbus was: gnome intrusion? Date: Sat, 19 Nov 2016 10:21:49 +0100 Message-ID: <20161119102149.0c62c7ad@jupiter.sol.kaishome.de> References: <20161114213743.55a5e76a@jupiter.sol.kaishome.de> <20161116124726.GA8424@g0n.xdwgrp> <20161117074400.7908.242EA9B5@matica.foolinux.mooo.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@blaine.gmane.org X-Newsreader: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) X-Archives-Salt: 427fd4b1-81df-4e74-8b33-4640d5f01546 X-Archives-Hash: f9f4b571eedba49e1ebdf5f48ff7a909 Am Thu, 17 Nov 2016 04:08:31 -0500 schrieb Rich Freeman : > On Thu, Nov 17, 2016 at 2:56 AM, Ian Zimmerman > wrote: > > On 2016-11-16 20:48, Rich Freeman wrote: > > > >> Policykit also lets you do stuff like saying this user is allowed > >> to restart this service, but not do anything else, and so on, > >> using a configuration which is flexible and works across different > >> applications/etc. > > > > I'm curious what you mean by "service" here. Surely not the things > > managed by rc-service, only root can touch them, right? Or regular > > users via sudo, and then sudo config restricts what they can do. > > > > I'm _guessing_ you mean desktop services like gnome-settings, and my > > retort is, I don't have any of those, and I never will. > > > > No, I mean services as in stuff like apache, gnome, and so on. > However, this was probably not a great example as it looks like none > of the service managers actually support policykit for this right now, > which means that only root can use these dbus commands. I think systemd supports it, tho I don't know how granular that can be made. Ideally, on a systemd machine, also desktop services are managed by a user instance of systemd. In this case, the user is already able to manage all these services. But most DEs still bring their own service manager (like kded in KDE I think), managed through dbus with an incompatible interface to systemd. The only systemd-native services in my DE is currently pulseaudio, invaded by a few service brought by Gnome components, including the aforementioned at-spi-dbus-bus.service which I masked. Of course, dbus is part of this systemd user instance. I've just taken another look at "systemctl --user status" and it looks like more and more KDE services are also started from systemd now through dbus activation. I wonder which components I could remove from /etc/xdg/autostart so these are only started on demand through dbus activation. In the end, systemd /can/ make your system slimmer by starting services (user and system) only on demand through dbus activation (or socket activation). > A better example might be doing things like changing the hostname, > without being root, or start/stop a container/vm. That's possible with policy-kit, tho I still think configuration through XML is overly complex. A much simpler format could do, plus make it actually human-readable. > Sure, you can also do some of this using sudo, but sudo isn't actually > a great tool for this as it is oriented around command line syntax, > and not functional privileges. The whole point of something like > dbus/policykit is that you define what you want somebody to be able to > do, not what commands they can type in order to try to do it. Using sudoers configuration is a huge security pita if you don't exactly know what you do configure. Plus, it is quite cumbersome when it comes to only parsing command lines for decision. Especially on a server, I do not really feel comfortable with that. > dbus support for these sorts of administrative functions is still > somewhat limited, and I suspect it will remain so until it is > completely merged into the kernel (or rather, bus1 is). I think it's rather missing some good frontend utilities (GUI and CLI). Especially combined with policy-kit. > It is also > somewhat new for these sorts of things. Previously it was more > focused on desktop-like functionality, such as loading icc color > profiles (apparently one of things you never will need). Well, I think the "d" actually comes from "desktop". But with systemd deployments, it also provides function for servers and their management. I think, a lot can still be explored here. It's actually useful. Tho, I'd also prefer a native kernel implementation with dbus only sitting on top of it as a compatibility layer until all DEs adapted it. > Ultimately though the concept is a pretty sound one. There are lots > of things done in userspace where you'd want the same kind of > granularity that posix capabilities offer in kernel space, and > policykit is a way to eventually manage these. UID=0 vs UID!=0 was > once nice upon a time, but it isn't great for security, and the > previous ways of addressing that tended to be lacking in various ways. Well, let's wait for the argument "but this is not the unix way". ;-) -- Regards, Kai Replies to list-only preferred.