From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: [PATCHES] Update elogind to 219.13 Date: Mon, 07 Mar 2016 09:52:22 +0100 Message-ID: <871t7m7jqx.fsf@igalia.com> References: <877fhf8n4f.fsf@pobox.com> <87a8mbe1cl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acqu0-0000OC-3B for guix-devel@gnu.org; Mon, 07 Mar 2016 03:52:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acqtw-0001vK-1Z for guix-devel@gnu.org; Mon, 07 Mar 2016 03:52:32 -0500 In-Reply-To: <87a8mbe1cl.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 06 Mar 2016 22:35:38 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org On Sun 06 Mar 2016 22:35, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Andy Wingo skribis: > >> 2. How elogind maps PIDs to sessions >> ------------------------------------ >> >> Systemd uses cgroups in two ways: one, to organize the tree of processes >> into users, slices, machines, sessions, and scopes; and two, to allow >> the user to balance resource usage between users, slices, etc. > > systemd-logind already uses a cgroup like /sys/fs/cgroups/elogind, > right? Yes, but it's managed by the systemd part (rather than logind) and called /sys/fs/cgroups/systemd. logind has to do RPC to systemd to wrangle the groups. I forgot to mention one thing. So, the original cgroups work gives the ability to partition the set of PIDs on a system using a custom hierarchy. However it becomes complicated because resource controllers (sometimes called "subsystems") can only be attached to one of those hierarchies. Because in systemd you often want to group and also control, systemd can attach a configurable set of controllers to its hierarchy also. This configuration can be a bit of a mess. This multi-rooted hierarchy of control is a flaw in the design of cgroups that is fixed with what's called the "unified cgroups", or cgroups v2. https://lwn.net/Articles/601840/ Cgroups v2 just landed in the kernel: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Doc= umentation/cgroup-v2.txt But cgroups v1, which is what we use, will be around for a long time. I haven't fully grokked the new cgroups to know how to use them. We can switch at some point in the future. >> Polkit 0.113 broke "pkexec" in the case where your desktop environment >> didn't already install a polkit authentication agent. > > Would it make sense to apply your patch until upstream has a better fix? > What are the risks? The risk is that somehow I have introduced a flaw that allows local root escalation. I have the patch applied but I don't think it's a good thing to ship in a distro without review. I would hold off on it for now, it's only good in the case that you use the built-in authentication agent in pkexec, and then only if you need to authenticate using PAM rather than because some rule gave you implicit permissions. Will adapt to feedback and land patches, thanks for review :) Andy