From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCHES] Update elogind to 219.13 Date: Mon, 07 Mar 2016 11:01:56 +0100 Message-ID: <87pov6vc6j.fsf@gnu.org> References: <877fhf8n4f.fsf@pobox.com> <87a8mbe1cl.fsf@gnu.org> <871t7m7jqx.fsf@igalia.com> 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]:36774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acrzG-00030h-Tx for guix-devel@gnu.org; Mon, 07 Mar 2016 05:02:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acrzE-0001UH-7l for guix-devel@gnu.org; Mon, 07 Mar 2016 05:02:02 -0500 In-Reply-To: <871t7m7jqx.fsf@igalia.com> (Andy Wingo's message of "Mon, 07 Mar 2016 09:52:22 +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: Andy Wingo Cc: guix-devel@gnu.org Andy Wingo skribis: > 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. Oh right, I remember you mentioned it before. > 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/D= ocumentation/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. Cool, makes sense. >>> 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. OK, better wait for upstream to provide a patch, indeed. BTW, a few days ago we were discussing on IRC the fact that elogind would start before dbus-daemon, and thus get respawned a couple of times at system startup, etc. Yesterday, with commit 956ad60, I changed it to be started through D-Bus activation, so we should be safe now. Cheers, Ludo=E2=80=99.