[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’.