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: Andy Wingo
Subject: Re: [PATCHES] Update elogind to 219.13
Date: Mon, 07 Mar 2016 09:52:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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.

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.

>> 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



reply via email to

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