guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCHES] Update elogind to 219.13


From: Ludovic Courtès
Subject: Re: [PATCHES] Update elogind to 219.13
Date: Mon, 07 Mar 2016 11:01:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Andy Wingo <address@hidden> skribis:

> On Sun 06 Mar 2016 22:35, address@hidden (Ludovic Courtès) writes:
>
>> Andy Wingo <address@hidden> 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/Documentation/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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]