[PATCHES] Update elogind to 219.13

[PATCHES] Update elogind to 219.13

[Andy Wingo]

[-- Attachment #1: Type: text/plain, Size: 6519 bytes --]

Hi,

Success!  Mostly :)  A table of contents:

  1. What is now possible
  2. How elogind maps PIDs to sessions
  3. GuixSD caveats


1. What is now possible
-----------------------

The attached patches update to the latest elogind, for which I just cut
a new release.  The big change is that elogind can now map PIDs to
sessions.  Elogind already keeps an idea of what sessions are "active".
On the other hand, polkit can implicitly grant some permissions to
"active" users.  This set of permissions is initially empty but it can
be augmented by other services, like gnome-settings-daemon.  In the
specific case of gnome-settings-daemon, gnome-settings-daemon ships an
.action file that allows the active user to invoke a helper that can
change the backlight of your screen.  For example:

    $ tail /etc/polkit-1/actions/org.gnome.settings-daemon.plugins.power.policy 
        <message xml:lang="zh_TW">修改筆記型電腦亮度需要核對</message>
        <defaults>
          <allow_any>no</allow_any>
          <allow_inactive>no</allow_inactive>
          <allow_active>yes</allow_active>
        </defaults>
        <annotate key="org.freedesktop.policykit.exec.path">/gnu/store/rssyvyd0dj0j5jqkmir0najq1rcd72il-gnome-settings-daemon-3.18.2/libexec/gsd-backlight-helper</annotate>
      </action>

    $ /gnu/store/rssyvyd0dj0j5jqkmir0najq1rcd72il-gnome-settings-daemon-3.18.2/libexec/gsd-backlight-helper --set-brightness 500
    This program can only be used by the root user

    $ pkexec /gnu/store/rssyvyd0dj0j5jqkmir0najq1rcd72il-gnome-settings-daemon-3.18.2/libexec/gsd-backlight-helper --set-brightness 500
    $

That last pkexec call checked remotely if polkit allowed this
invocation, and whee, it did, so pkexec did a setuid() to root and
invoked the binary:

    $ tail /var/log/secure
    [...]
    Mar  6 19:12:34 localhost pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
    Mar  6 19:12:34 localhost pkexec[1885]: wingo: Executing command [USER=root] [TTY=/dev/pts/0] [CWD=/home/wingo/src/elogind] [COMMAND=/gnu/store/rssyvyd0dj0j5jqkmir0najq1rcd72il-gnome-settings-daemon-3.18.2/libexec/gsd-backlight-helper --set-brightness 500]

This is the exact mechanism that gnome-settings-daemon uses to set the
backlight, so we are doing great!


This isn't just theoretical; gnome-settings-
    ./plugins/power/gpm-common.c:514:        command = g_strdup_printf ("pkexec " LIBEXECDIR "/gsd-backlight-helper --%s %i",


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.

In contrast, elogind only uses cgroups to organize processes, and since
it doesn't try to control resource usage, it can just organize them into
sessions.  It turns out that you can make cgroups that are just for
organization, not for controlling any particular resource.  (See
http://0pointer.de/blog/projects/cgroups-vs-cgroups.html, for more.)

So that's what elogind does.  When pam_elogind tells the logind about a
new session, elogind will create a new cgroup for that session and
migrate the session leader into the new cgroup, assuming that the only
process in the session is the session leader.  From then on, all
children of that PID, even if they double-fork, are marked as being in
the e.g. /sys/fs/cgroups/elogind/c1 cgroup.

And yes, the interface to cgroups really is the file system.  Pretty
weird.  The other cgroups that correspond to resource controllers like
"cpuset" and "memory" have their own mounts, eg /sys/fs/cgroups/memory.
So one of these patches adds a mount for the elogind cgroup hierarchy.

From then on out, to know what cgroup a process is in, you just cat a
special file in /proc.  For example:

    $ cat /proc/$(pgrep gnome-terminal)/cgroup
    10:name=elogind:/c1
    9:cpuset:/
    8:cpu:/
    7:cpuacct:/
    6:memory:/
    5:devices:/
    4:freezer:/
    3:blkio:/
    2:perf_event:/
    1:hugetlb:/

So my gnome-terminal is running in cgroup /c1, which because elogind
controls that cgroup tree, we interpret to mean that it is running in
the "c1" session.  Voilà.

Conversely to know what PIDs are in a session:

    $ cat /sys/fs/cgroup/elogind/c1/cgroup.procs 
    346
    411
    420
    [...]
   

3. Caveats
----------

Polkit 0.113 broke "pkexec" in the case where your desktop environment
didn't already install a polkit authentication agent.

The background is, it's usually graphical applications that want to do
things on your behalf as root or some other user, and you might need to
authenticate yourself or even authenticate as root to do the action.
However it would be ~~~~~clownshoes pants-on-fire zaniness~~~~~~~ if
apps popped up dialog boxes asking you to put in the root password.
Probably those apps have security vulnerabilities, and it can be hard to
know if you should trust the app with those credentials, or trust the
app as root, or trust that the permissions it appears to be asking you
for correspond with what it's actually going to do.  So desktop
environments ship graphical authentication agents that are carefully
coded to be able to use credentials in a very limited way: only to
*answer* the polkit daemon's query that a user is authenticated.

But in the absence of such an auth agent, it could be that pkexec has to
install one on its own, to allow you to enter your password on the
console.  It's setuid IPC madness but I have followed most of the code
paths and I am OK with it.

But, this fallback console agent is broken in 0.113:
https://bugs.freedesktop.org/show_bug.cgi?id=90837.  So should polkit
need to ask you for a password, it will take your password but then fail
to authenticate.  I have a patch to fix it:
http://thread.gmane.org/gmane.comp.gnu.guix.devel/16906 but probably
something else will go upstream (check that bug).

For the specific permissions about the backlight helper, you need
http://thread.gmane.org/gmane.comp.gnu.guix.devel/16937.  Need to push
that one along.

Finally to actually have your backlight keys work, there is something
still missing -- gnome-settings-daemon has to run and I don't have that
fully working yet.  Perhaps some other brave soul will get on this :)

Happy hacking,

Andy


[-- Attachment #2: 0001-gnu-system-Add-elogind-cgroup-mount.patch --]
[-- Type: text/plain, Size: 1251 bytes --]

From f9911bdc3ff24999b5b961f299f4a3b4461c381c Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@igalia.com>
Date: Wed, 2 Mar 2016 20:29:47 +0100
Subject: [PATCH 1/2] gnu: system: Add elogind cgroup mount.

* gnu/system/file-systems.scm (%elogind-file-systems): Add elogind
  cgroup mount.
---
 gnu/system/file-systems.scm | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gnu/system/file-systems.scm b/gnu/system/file-systems.scm
index d93044c..0891ed2 100644
--- a/gnu/system/file-systems.scm
+++ b/gnu/system/file-systems.scm
@@ -232,7 +232,16 @@ initrd code."
           (check? #f)
           (flags '(no-suid no-dev no-exec))
           (options "mode=0755")
-          (create-mount-point? #t))))
+          (create-mount-point? #t))
+        ;; Elogind uses cgroups to organize processes, not to control them.
+        (file-system
+          (device "cgroup")
+          (mount-point "/sys/fs/cgroup/elogind")
+          (type "cgroup")
+          (check? #f)
+          (options "none,name=elogind")
+          (create-mount-point? #t)
+          (dependencies (list (car %control-groups))))))
 
 (define %base-file-systems
   ;; List of basic file systems to be mounted.  Note that /proc and /sys are
-- 
2.6.3


[-- Attachment #3: 0002-gnu-elogind-Update-to-219.13.patch --]
[-- Type: text/plain, Size: 2424 bytes --]

From c4d97c9ea8f1ee48d847895e9b3ef974daa4fbdc Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@igalia.com>
Date: Sun, 6 Mar 2016 19:00:29 +0100
Subject: [PATCH 2/2] gnu: elogind: Update to 219.13.

* gnu/packages/freedesktop.scm (elogind): Update to 219.13.  Remove
  build fix that is no longer needed.  Update home page.
---
 gnu/packages/freedesktop.scm | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/freedesktop.scm b/gnu/packages/freedesktop.scm
index 6a28379..b6f6792 100644
--- a/gnu/packages/freedesktop.scm
+++ b/gnu/packages/freedesktop.scm
@@ -142,14 +142,14 @@ the freedesktop.org XDG Base Directory specification.")
 (define-public elogind
   (package
     (name "elogind")
-    (version "219.12")
+    (version "219.13")
     (source (origin
               (method url-fetch)
               (uri (string-append "https://wingolog.org/pub/" name "/"
                                   name "-" version ".tar.xz"))
               (sha256
                (base32
-                "13qc4f0dl7ynnfp1y565z2k0jjizly5w3dqhiqkdk7v6jr4pksb7"))
+                "0swwsgm28radjxf0s05a907wf0n524lckdya0rm3kqw6gy1hiax2"))
               (modules '((guix build utils)))
               (snippet
                '(begin
@@ -165,10 +165,7 @@ the freedesktop.org XDG Base Directory specification.")
                             (assoc-ref %build-inputs "libcap"))
              (string-append "--with-udevrulesdir="
                             (assoc-ref %outputs "out")
-                            "/lib/udev/rules.d")
-             ;; XXX: fail with:
-             ;;  src/shared/clean-ipc.c:315: undefined reference to `mq_unlink'
-             "LDFLAGS=-lrt")
+                            "/lib/udev/rules.d"))
        #:make-flags '("PKTTYAGENT=/run/current-system/profile/bin/pkttyagent")))
     (native-inputs
      `(("intltool" ,intltool)
@@ -188,7 +185,7 @@ the freedesktop.org XDG Base Directory specification.")
                                              ;when pressing the power button
        ("dbus" ,dbus)
        ("eudev" ,eudev)))
-    (home-page "https://github.com/andywingo/elogind")
+    (home-page "https://github.com/wingo/elogind")
     (synopsis "User, seat, and session management service")
     (description "Elogind is the systemd project's \"logind\" service,
 extracted out as a separate project.  Elogind integrates with PAM to provide
-- 
2.6.3

Re: [PATCHES] Update elogind to 219.13

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> 1. What is now possible
> -----------------------
>
> The attached patches update to the latest elogind, for which I just cut
> a new release.  The big change is that elogind can now map PIDs to
> sessions.  Elogind already keeps an idea of what sessions are "active".
> On the other hand, polkit can implicitly grant some permissions to
> "active" users.  This set of permissions is initially empty but it can
> be augmented by other services, like gnome-settings-daemon.  In the
> specific case of gnome-settings-daemon, gnome-settings-daemon ships an
> .action file that allows the active user to invoke a helper that can
> change the backlight of your screen.  For example:

Awesome!

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

Woow, thanks for the explanation and all.

systemd-logind already uses a cgroup like /sys/fs/cgroups/elogind,
right?

Anyway, that sounds great.  :-)

> 3. Caveats
> ----------
>
> Polkit 0.113 broke "pkexec" in the case where your desktop environment
> didn't already install a polkit authentication agent.
>
> The background is, it's usually graphical applications that want to do
> things on your behalf as root or some other user, and you might need to
> authenticate yourself or even authenticate as root to do the action.
> However it would be ~~~~~clownshoes pants-on-fire zaniness~~~~~~~ if
> apps popped up dialog boxes asking you to put in the root password.
> Probably those apps have security vulnerabilities, and it can be hard to
> know if you should trust the app with those credentials, or trust the
> app as root, or trust that the permissions it appears to be asking you
> for correspond with what it's actually going to do.  So desktop
> environments ship graphical authentication agents that are carefully
> coded to be able to use credentials in a very limited way: only to
> *answer* the polkit daemon's query that a user is authenticated.
>
> But in the absence of such an auth agent, it could be that pkexec has to
> install one on its own, to allow you to enter your password on the
> console.  It's setuid IPC madness but I have followed most of the code
> paths and I am OK with it.
>
> But, this fallback console agent is broken in 0.113:
> https://bugs.freedesktop.org/show_bug.cgi?id=90837.  So should polkit
> need to ask you for a password, it will take your password but then fail
> to authenticate.  I have a patch to fix it:
> http://thread.gmane.org/gmane.comp.gnu.guix.devel/16906 but probably
> something else will go upstream (check that bug).

Would it make sense to apply your patch until upstream has a better fix?
What are the risks?

> For the specific permissions about the backlight helper, you need
> http://thread.gmane.org/gmane.comp.gnu.guix.devel/16937.  Need to push
> that one along.

We’re getting there!

> Finally to actually have your backlight keys work, there is something
> still missing -- gnome-settings-daemon has to run and I don't have that
> fully working yet.  Perhaps some other brave soul will get on this :)

Heh.

> From f9911bdc3ff24999b5b961f299f4a3b4461c381c Mon Sep 17 00:00:00 2001
> From: Andy Wingo <wingo@igalia.com>
> Date: Wed, 2 Mar 2016 20:29:47 +0100
> Subject: [PATCH 1/2] gnu: system: Add elogind cgroup mount.
>
> * gnu/system/file-systems.scm (%elogind-file-systems): Add elogind
>   cgroup mount.
> ---
>  gnu/system/file-systems.scm | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/system/file-systems.scm b/gnu/system/file-systems.scm
> index d93044c..0891ed2 100644
> --- a/gnu/system/file-systems.scm
> +++ b/gnu/system/file-systems.scm
> @@ -232,7 +232,16 @@ initrd code."
>            (check? #f)
>            (flags '(no-suid no-dev no-exec))
>            (options "mode=0755")
> -          (create-mount-point? #t))))
> +          (create-mount-point? #t))
> +        ;; Elogind uses cgroups to organize processes, not to control them.

“to organize processes, not to control them.  This allows it to find out
which session a process is in and so on.”

(So the future me remembers what this is all about.  ;-))

> From c4d97c9ea8f1ee48d847895e9b3ef974daa4fbdc Mon Sep 17 00:00:00 2001
> From: Andy Wingo <wingo@igalia.com>
> Date: Sun, 6 Mar 2016 19:00:29 +0100
> Subject: [PATCH 2/2] gnu: elogind: Update to 219.13.
>
> * gnu/packages/freedesktop.scm (elogind): Update to 219.13.  Remove
>   build fix that is no longer needed.  Update home page.

OK!

Thanks for the insightful explanations!

Ludo’.

Re: [PATCHES] Update elogind to 219.13

[Andy Wingo]

On Sun 06 Mar 2016 22:35, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@igalia.com> 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

Re: [PATCHES] Update elogind to 219.13

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Sun 06 Mar 2016 22:35, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@igalia.com> 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’.

Re: [PATCHES] Update elogind to 219.13

[Andy Wingo]

On Mon 07 Mar 2016 11:01, ludo@gnu.org (Ludovic Courtès) writes:

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

FWIW I am not sure that this is the right solution.  Logind has some
other interfaces (notably the /run/systemd file system and the cgroups)
and it really wants to be running from beginning to end.  If it's
bus-activated, could it be killed at some point if it's inactive?  If so
that would be bad I think.

Maybe it's OK.  It certainly solves the race, in some way.  I think
before a "guix system reconfigure" would restart logind, also; is that
still the case?  Which is better?  Very murky to me.

Andy

Re: [PATCHES] Update elogind to 219.13

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Mon 07 Mar 2016 11:01, ludo@gnu.org (Ludovic Courtès) writes:
>
>> 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.
>
> FWIW I am not sure that this is the right solution.  Logind has some
> other interfaces (notably the /run/systemd file system and the cgroups)
> and it really wants to be running from beginning to end.  If it's
> bus-activated, could it be killed at some point if it's inactive?  If so
> that would be bad I think.

I think it wouldn’t miss any log-in, because as soon as you log in
pam_elogind calls out to elogind, at which point it is started if it’s
not running yet.

Also it seems to me that dbus-daemon never kills inactive daemons, does
it?

On systemd-based systems, does logind get started on demand?

It seems safe, but perhaps I overlooked something.

> Maybe it's OK.  It certainly solves the race, in some way.  I think
> before a "guix system reconfigure" would restart logind, also; is that
> still the case?  Which is better?  Very murky to me.

‘guix system reconfigure’ starts new services, and restarts services
that are currently stopped.

If the ‘elogind’ Shepherd service was already started at the time ‘guix
system reconfigure’ runs, it would conservatively leave it as is instead
of trying to upgrade and restart it.

Thanks,
Ludo’.