Groups > linux.debian.bugs.dist > #1224024 > unrolled thread

Bug#1076728: elogind: privileged operation with polkit fails

Started by	Andrew Bower <andrew@bower.uk>
First post	2024-12-14 22:20 +0100
Last post	2024-12-17 20:20 +0100
Articles	20 on this page of 29 — 7 participants

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

  Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-14 22:20 +0100
    Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-14 23:30 +0100
      Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-14 23:50 +0100
        Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-16 18:50 +0100
          Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-16 22:50 +0100
            Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-17 08:40 +0100
          Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-17 01:10 +0100
            Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-17 09:30 +0100
              Bug#1076728: elogind: privileged operation with polkit fails Simon McVittie <smcv@debian.org> - 2024-12-17 12:00 +0100
                Bug#1076728: elogind: privileged operation with polkit fails tito <farmatito@tiscali.it> - 2024-12-17 14:50 +0100
                  Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-17 19:00 +0100
                Bug#1076728: elogind: privileged operation with polkit fails Yves-Alexis Perez <corsac@corsac.net> - 2024-12-17 15:10 +0100
                  Bug#1076728: elogind: privileged operation with polkit fails Simon McVittie <smcv@debian.org> - 2024-12-17 20:10 +0100
                    Bug#1076728: elogind: privileged operation with polkit fails Simon McVittie <smcv@debian.org> - 2024-12-17 21:30 +0100
                Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-17 17:50 +0100
                  Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-17 20:20 +0100
                    Bug#1076728: elogind: privileged operation with polkit fails Simon McVittie <smcv@debian.org> - 2024-12-17 21:00 +0100
                      Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-18 11:20 +0100
                        Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-18 19:40 +0100
                          Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-18 20:10 +0100
                            Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2024-12-18 21:00 +0100
                            Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2024-12-19 11:00 +0100
                              Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2025-01-07 20:40 +0100
                                Bug#1076728: elogind: privileged operation with polkit fails Thorsten Glaser <tg@evolvis.org> - 2025-01-07 21:40 +0100
                                  Bug#1076728: elogind: privileged operation with polkit fails Mark Hindley <mark@hindley.org.uk> - 2025-01-08 08:40 +0100
                                    Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2025-01-08 10:00 +0100
                                      Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.uk> - 2025-01-08 10:30 +0100
                    Bug#1076728: elogind: privileged operation with polkit fails Andrew Bower <andrew@bower.org.uk> - 2024-12-17 21:40 +0100
                  Bug#1076728: elogind: privileged operation with polkit fails Simon McVittie <smcv@debian.org> - 2024-12-17 20:20 +0100

Page 1 of 2 [1] 2 Next page →

#1224024 — Bug#1076728: elogind: privileged operation with polkit fails

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-14 22:20 +0100
Subject	Bug#1076728: elogind: privileged operation with polkit fails
Message-ID	<JTHIl-h3wj-1@gated-at.bofh.it>

Hi Mark,

On Mon, Jul 22, 2024 at 09:01:58PM +0100, Mark Hindley wrote:
> Control: tags -1 moreinfo unreproducible
> 
> Lorenzo,
> 
> Thanks for this
> 
> On Mon, Jul 22, 2024 at 08:06:56PM +0200, Lorenzo Puliti wrote:
> > Package: elogind
> > Version: 255.5-1debian2
> > Severity: important
> > X-Debbugs-Cc: plorenzo@disroot.org
> > 
> > Hello Mark,
> > 
> > with elogind linked to libsystemd0 privileged operations with polkit
> > no longer work, example:
> 
> I am afraid I can't reproduce this. I have just tried a VM (lightdm, xfce latest dbus, polkitd
> libpam-elogind and libsystemd) and everything seems to as expected.

I have the same problem - no restart or shutdown options from xfce4 and
can't do elevated operations, e.g. manage printers.

This machine is a recent installation converted to sysvinit after
installation. Although I also normally use runit as init, I haven't on
this desktop.

I thought this had initially been working but I may be mistaken: systemd
did not last long:

2024-11-11 22:47:43 install systemd:amd64 <none> 257~rc1-4
2024-11-11 23:04:40 install sysvinit-core:amd64 <none> 3.11-1
2024-11-11 23:07:01 install elogind:amd64 <none> 255.5-1debian3

> I don't see anything in the logs you provided either (other than the
> InteractiveAuthorizationRequired failure). Have you got any custom polkit rules?
> The latest polkicykit-1 removed the pkla compatibility[1]

I don't have any custom polkit rules. I do have additional settings
supporting login via samba AD. This issue occurs regardless of whether I
use that or shadow password to log in to X session. debsums -ac did
not suggest anything interesting.

Anything I can do or provide to help diagnose?

> I will keep trying.
> 
> Mark

My system details:

Package: elogind
Version: 255.5-1debian3

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.3-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages elogind depends on:
ii  dbus                 1.15.92-1
ii  debconf              1.5.87
ii  init-system-helpers  1.67
ii  libacl1              2.3.2-2+b1
ii  libc6                2.40-4
ii  libcap2              1:2.66-5+b1
ii  libmount1            2.40.2-12
ii  libpam0g             1.5.3-7+b1
ii  libselinux1          3.7-3+b1
ii  libsystemd0          257~rc1-4
ii  libudev1             257-2

Versions of packages elogind recommends:
ii  libpam-elogind  255.5-1debian3
ii  polkitd         125-2

Other software:
ii  lightdm                                      1.32.0-6+b1
ii  xfce4                                        4.18
ii  libpam-gnome-keyring:amd64                   46.2-1         
ii  libpam-krb5:amd64                            4.11-2+b1      
ii  libpam-modules:amd64                         1.5.3-7+b1     
ii  libpam-modules-bin                           1.5.3-7+b1     
ii  libpam-runtime                               1.5.3-7        
ii  libpam-u2f                                   1.3.0-1        
ii  libpam-winbind:amd64                         2:4.21.2+dfsg-4
ii  libpam-wtmpdb:amd64                          0.13.0-1       
ii  libpam0g:amd64                               1.5.3-7+b1

[toc] | [next] | [standalone]

#1224030

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-14 23:30 +0100
Message-ID	<JTIO5-h4bc-13@gated-at.bofh.it>
In reply to	#1224024

Andrew,

On Sat, Dec 14, 2024 at 09:12:35PM +0000, Andrew Bower wrote:
> LSM: AppArmor: enabled

Is there anything in the apparmor log? Does disabling or removing it 
help?

Mark

[toc] | [prev] | [next] | [standalone]

#1224032

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-14 23:50 +0100
Message-ID	<JTJ7r-h4ij-5@gated-at.bofh.it>
In reply to	#1224030

On Sat, Dec 14, 2024 at 10:22:39PM +0000, Mark Hindley wrote:
> On Sat, Dec 14, 2024 at 09:12:35PM +0000, Andrew Bower wrote:
> > LSM: AppArmor: enabled
> 
> Is there anything in the apparmor log?

No.

> Does disabling or removing it help?

Sadly not. I have now removed it - no LSM active - but same symptoms
prevail.

[toc] | [prev] | [next] | [standalone]

#1224284

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-16 18:50 +0100
Message-ID	<JUnod-hABu-1@gated-at.bofh.it>
In reply to	#1224032

Andrew,

I am afraid I still can't reproduce this.

Check some basics please. I have the following installed:

test@DebianUnstable:~$ dpkg -l|grep -E 'polkit|elogind|systemd'|grep ^ii
ii  elogind                              255.5-1debian3                     amd64        user, seat and session management daemon
ii  libpam-elogind:amd64                 255.5-1debian3                     amd64        elogind PAM module
ii  libpam-elogind-compat:amd64          1.3                                amd64        Compatibility package for testing integration of libpam-elogind into Debian
ii  libpolkit-agent-1-0:amd64            125-2                              amd64        polkit Authentication Agent API
ii  libpolkit-gobject-1-0:amd64          125-2                              amd64        polkit Authorization API
ii  polkitd                              125-2                              amd64        framework for managing administrative policies and privileges
ii  libsystemd0:amd64 			 257-2        			    amd64        systemd utility library

All lightdm* PAM configs should include common-session:

test@DebianUnstable:~$ grep common-session /etc/pam.d/lightdm*
/etc/pam.d/lightdm:@include common-session
/etc/pam.d/lightdm-autologin:@include common-session
/etc/pam.d/lightdm-greeter:@include common-session

PAM common-session should include pam_elogind.so:

test@DebianUnstable:~$ grep elogind /etc/pam.d/common-session
session optional                        pam_elogind.so 

With that, when you login you should have a valid session:

test@DebianUnstable:~$ loginctl
SESSION  UID USER    SEAT  TTY STATE   IDLE SINCE
      1 1000 test    seat0 -   active  no   -    
     c1  105 lightdm seat0 -   closing no   -    

2 sessions listed.

and that session can be used to gain privs (you might need to install pkexec)

test@DebianUnstable:~$ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: Test User,,, (test)
Password: 
==== AUTHENTICATION COMPLETE ====
uid=0(root) gid=0(root) groups=0(root)

All lightdm and xfce hibernate/restart/shutdown options are available and functional.

Which steps give you different results?

Mark

[toc] | [prev] | [next] | [standalone]

#1224357

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-16 22:50 +0100
Message-ID	<JUr8t-4l7-1@gated-at.bofh.it>
In reply to	#1224284

Hi Mark,

On Mon, Dec 16, 2024 at 05:41:57PM +0000, Mark Hindley wrote:
> I am afraid I still can't reproduce this.

Thank you so much for following up!

> Check some basics please. I have the following installed:
> 
> test@DebianUnstable:~$ dpkg -l|grep -E 'polkit|elogind|systemd'|grep ^ii
> ii  elogind                              255.5-1debian3                     amd64        user, seat and session management daemon
> ii  libpam-elogind:amd64                 255.5-1debian3                     amd64        elogind PAM module
> ii  libpam-elogind-compat:amd64          1.3                                amd64        Compatibility package for testing integration of libpam-elogind into Debian
> ii  libpolkit-agent-1-0:amd64            125-2                              amd64        polkit Authentication Agent API
> ii  libpolkit-gobject-1-0:amd64          125-2                              amd64        polkit Authorization API
> ii  polkitd                              125-2                              amd64        framework for managing administrative policies and privileges
> ii  libsystemd0:amd64 			 257-2        			    amd64        systemd utility library

I have some additional packages, but otherwise the same
(libpam-elogind-compat virtual package does not seem to be available to
install - I didn't look into it further):

-------- ✂ --------
$ dpkg -l|grep -E 'polkit|elogind|systemd'|grep ^ii
ii  elogind                      255.5-1debian3  amd64  user, seat and session management daemon
ii  gir1.2-polkit-1.0            125-2           amd64  GObject introspection data for polkit
ii  libpam-elogind:amd64         255.5-1debian3  amd64  elogind PAM module
ii  libpolkit-agent-1-0:amd64    125-2           amd64  polkit Authentication Agent API
ii  libpolkit-gobject-1-0:amd64  125-2           amd64  polkit Authorization API
ii  libpolkit-gobject-1-dev      125-2           amd64  polkit Authorization API - development files
ii  libsystemd-dev:amd64         257-2           amd64  systemd utility library - development files
ii  libsystemd-shared:amd64      257-2           amd64  systemd shared private library
ii  libsystemd0:amd64            257-2           amd64  systemd utility library
ii  pkexec                       125-2           amd64  run commands as another user with polkit authorization
ii  polkitd                      125-2           amd64  framework for managing administrative policies and privileges
ii  runit-run                    2.1.2-60        all    service supervision (systemd and sysv integration)
ii  systemctl                    1.4.4181-1.1    all    daemonless "systemctl" command to manage services without systemd
ii  systemd-dev                  257-2           all    systemd development files
ii  systemd-standalone-sysusers  257-2           amd64  standalone sysusers binary for use in non-systemd systems
-------- ✂ --------

> All lightdm* PAM configs should include common-session:
> 
> test@DebianUnstable:~$ grep common-session /etc/pam.d/lightdm*
> /etc/pam.d/lightdm:@include common-session
> /etc/pam.d/lightdm-autologin:@include common-session
> /etc/pam.d/lightdm-greeter:@include common-session
> 
> PAM common-session should include pam_elogind.so:
> 
> test@DebianUnstable:~$ grep elogind /etc/pam.d/common-session
> session optional                        pam_elogind.so 
> 
> With that, when you login you should have a valid session:
> 
> test@DebianUnstable:~$ loginctl
> SESSION  UID USER    SEAT  TTY STATE   IDLE SINCE
>       1 1000 test    seat0 -   active  no   -    
>      c1  105 lightdm seat0 -   closing no   -    
> 
> 2 sessions listed.
> 
> and that session can be used to gain privs (you might need to install pkexec)
> 
> test@DebianUnstable:~$ pkexec id
> ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
> Authentication is needed to run `/usr/bin/id' as the super user
> Authenticating as: Test User,,, (test)
> Password: 
> ==== AUTHENTICATION COMPLETE ====
> uid=0(root) gid=0(root) groups=0(root)
> 
> All lightdm and xfce hibernate/restart/shutdown options are available and functional.
> 
> Which steps give you different results?

The other steps produced no difference:

-------- ✂ --------
$ grep common-session /etc/pam.d/lightdm*
/etc/pam.d/lightdm:@include common-session
/etc/pam.d/lightdm-autologin:@include common-session
/etc/pam.d/lightdm-greeter:@include common-session
$ grep elogind /etc/pam.d/common-session
session	optional			pam_elogind.so 
$ loginctl
SESSION  UID USER    SEAT  TTY STATE   IDLE SINCE
      1 1000 andy    seat0 -   active  no   -    
     c1  108 lightdm seat0 -   closing no   -    

2 sessions listed.
$ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: Andrew Bower,,, (andy)
Password: 
==== AUTHENTICATION COMPLETE ====
uid=0(root) gid=0(root) groups=0(root)
-------- ✂ --------

I have another desktop system which also reproduces this and two that
don't:

 +-----------+---------------------+------------------+---------+--------+
 | # | arch  | Installation        | Current          | DM      | Result |
 |   |       | OS       | init     | OS       | init  | DE      |        |
 +===+=======+=====================+==================+=========+========+
 | A | amd64 | debian/  | systemd  | debian/  | sysv  | lightdm | FAIL   |
 |   |       | unstable |          | unstable |       | xfce4   |        |
 +---+-------+---------------------+------------------+---------+--------+
 | B | i386  | debian/  | systemd  | debian/  | sysv  | lightdm | FAIL   |
 |   |       | unstable |          | unstable |       | xfce4   |        |
 +---+-------+---------------------+------------------+---------+--------+
 | C | amd64 | debian/  | systemd  | debian/  | runit | slim    | PASS   |
 |   |       | bookworm | then sysv| unstable |       | xfce4   |        |
 +---+-------+---------------------+------------------+---------+--------+
 | D | amd64 | devuan/  | runit    | devuan/  | runit | slim    | PASS   |
 |   | amd64 | testing  |          | unstable |       | xfce4   |        |
 +-----------+---------------------+------------------+---------+--------+

Another feature that fails due to this issue is access to smartcard via
pscd, which reports:

2024-12-16T14:37:57.756789+00:00 shenstone pcscd: ../src/auth.c:145:IsClientAuthorized() Process 3349 (user: 1000) is NOT authorized for action: access_pcsc
2024-12-16T14:37:57.756838+00:00 shenstone pcscd: ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client

[toc] | [prev] | [next] | [standalone]

#1224410

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-17 08:40 +0100
Message-ID	<JUAlr-aJ3-3@gated-at.bofh.it>
In reply to	#1224357

On Mon, Dec 16, 2024 at 09:41:31PM +0000, Andrew Bower wrote:
> I have some additional packages, but otherwise the same
> (libpam-elogind-compat virtual package does not seem to be available to
> install - I didn't look into it further):

That is cruft. I have removed it with no change.

Mark

[toc] | [prev] | [next] | [standalone]

#1224387

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-17 01:10 +0100
Message-ID	<JUtjX-6ee-3@gated-at.bofh.it>
In reply to	#1224284

On Mon, Dec 16, 2024 at 05:41:57PM +0000, Mark Hindley wrote:
[...]
> All lightdm and xfce hibernate/restart/shutdown options are available and functional.
      ^^^^^^^

This made me check: the lightdm controls are also unavailable so that
perhaps limits the scope of the problem.

My lightdm processes:

$ ps auwwx | grep lightdm
root      2417  0.0  0.0 307080  6232 ?        SLl  14:37   0:00 /usr/sbin/lightdm
root      2642  1.2  0.7 2746208 231252 tty7   Ssl+ 14:37   7:12 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
lightdm   2870  0.0  0.0   6684  2136 ?        S    14:37   0:00 dbus-launch --autolaunch=9fdab11bf0014964a9e094087197ff45 --binary-syntax --close-stderr
lightdm   2879  0.0  0.0   7940  2332 ?        Ss   14:37   0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
lightdm   2884  0.0  0.0 230580  5452 ?        Sl   14:37   0:00 /usr/libexec/dconf-service
lightdm   2966  0.0  0.0 380884  7120 ?        Sl   14:37   0:00 /usr/libexec/at-spi-bus-launcher
lightdm   2972  0.0  0.0   7916  4420 ?        S    14:37   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 11 --address=unix:path=/run/user/108/at-spi/bus_0
root      3013  0.0  0.0 244608 12620 ?        Sl   14:37   0:00 lightdm --session-child 13 20
lightdm   3015  0.0  0.0 234116  7436 ?        Sl   14:37   0:00 /usr/libexec/at-spi2-registryd --use-gnome-session

[toc] | [prev] | [next] | [standalone]

#1224413

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-17 09:30 +0100
Message-ID	<JUB7P-bfd-3@gated-at.bofh.it>
In reply to	#1224387

On Tue, Dec 17, 2024 at 12:04:00AM +0000, Andrew Bower wrote:
> On Mon, Dec 16, 2024 at 05:41:57PM +0000, Mark Hindley wrote:
> [...]
> > All lightdm and xfce hibernate/restart/shutdown options are available and functional.
>       ^^^^^^^
> 
> This made me check: the lightdm controls are also unavailable so that
> perhaps limits the scope of the problem.

I am not sure it does, other than pointing to the same underlying failure. AIUI,
all processes (lightdm, xfce4-session, pcscd...) use the same dbus
integration. I am perplexed why 'pkexec id' works but nothing further. This
still suggests to me some local configuration issue. I hope Simon can help.

Simon,

We would appreciate your expertise here. I appreciate that you have no specific
interested in non-systemd polkit integration. However, I am not convinced this
is an elogind-specific issue; I haven't (yet) retitled the bug, because we have
failed to identify the root cause and it remains unreproducible for me.

In short, several users have reported failure of desktop polkit integration on
systems using elogind.

Basic testing of the libpam-elogind stack appears OK: loginctl reports a
registered session and 'pkexec id' prompts for a password and reports root.

However, all 'desktop' polkit integration appears non-functional
(reboot/hibernate/shutdown in lightdm an xfce4, pcscd mount etc...).  The DBus
error is InteractiveAuthorizationRequired. Neither reporter has any custom
polkit configuration.

Any suggestions you have for debugging this further or identifying the cause
would be much appreciated. Thanks.

Mark

[toc] | [prev] | [next] | [standalone]

#1224433

From	Simon McVittie <smcv@debian.org>
Date	2024-12-17 12:00 +0100
Message-ID	<JUDsZ-cB5-15@gated-at.bofh.it>
In reply to	#1224413

Context for XFCE and polkitd maintainers (cc'd): a user of XFCE on a
sysvinit/elogind system has found that authorizing privileged operations
via polkit is not working as intended. I'm not at all sure that this is
actually an elogind problem: it might be a result of XFCE not obviously
containing a polkit agent (the component that does the actual prompting).

On Tue, 17 Dec 2024 at 08:24:39 +0000, Mark Hindley wrote:
> Basic testing of the libpam-elogind stack appears OK: loginctl reports a
> registered session and 'pkexec id' prompts for a password and reports root.

An important difference between pkexec and most other polkit clients
is that pkexec has its own minimal built-in polkit agent, which is
used as a fallback if the desktop environment has not registered one
with polkitd. Is the prompt inline on the terminal, or is it a separate
window? And is the UI the same for the same desktop environment installed
on a test system (perhaps a VM) that was booted with systemd and has a
working `systemd --user`?

If the prompt was inline on the terminal, check that the desktop
environment is actually launching a polkit agent and registering it with
polkitd on the D-Bus system bus.

You can disable the internal agent for debugging by running a command like:

    pkexec --disable-internal-agent id

which would be closer to an apples-to-apples comparison with other polkit
clients. If this fails with the same error message that you have seen for
other privileged operations, then the problem is that your polkit agent
is absent or not correctly registered with polkitd.

Command-line tools like pkexec and flatpak often provide a fallback
agent on the terminal like this, so that they can be run from a non-GUI
session. GUI tools essentially never do: they expect to be run in a
desktop environment session where there is already a working polkit agent.

I am not familiar with XFCE, but I believe it is meant to include a polkit
agent of some sort? I can't find a particularly obvious candidate among
the packages that depend on libpolkit-agent-1-0 or provide
polkit-1-auth-agent, though. It might be helpful to install a standalone
polkit agent (perhaps lxpolkit or mate-polkit) and see what happens if you
run it manually before triggering a privileged operation.

polkit agents are similar to o.fd.Notification implementations in
that there is a de facto assumption that any "complete" desktop
environment should provide one. Some desktop environments include an
integrated polkit agent that is part of the desktop shell (examples:
budgie-core, cinnamon, gnome-shell, gnome-flashback, phosh), some have
a dependency on a desktop-specific standalone agent that is hopefully
started automatically as part of the desktop environment (examples:
KDE Plasma/polkit-kde-agent-1, UKUI/ukui-polkit, LXDE/lxpolkit,
LXQT/lxqt-policykit, MATE/mate-polkit), and environments that are more
like a kit of parts to build your own desktop environment tend to not
include one and assume that the user will do their own setup. I had
hoped that XFCE would be in the first or second categories.

Historically the polkit agent of last resort was policykit-1-gnome (which
was the one that was used in GNOME 2), but that one is unmaintained
upstream (a concerning situation for a security-critical component!) and
no longer accepts bug reports or merge requests, so the polkit maintainers
are trying to arrange for it not to be included in trixie (#990271).
Please do not rely on policykit-1-gnome. If it is the most suitable polkit
agent for XFCE, then the XFCE team will need to fork it and become the new
upstream maintainers of the fork.

If you suspect that systemd vs. not-systemd is part of the problem here:
some desktop environments use `systemd --user` for part of their session
startup, and might have different behaviour on less-tested fallback code
paths (or just not work at all) without it. I know that GNOME and
KDE Plasma both make some use of `systemd --user` for session startup;
I don't know whether XFCE does, but that might be another thing to look at.
An apples-to-apples comparison of two VMs that have the same package
set and desktop environment, except that one has libpam-systemd (+
dependencies) and the other has libpam-elogind (+ dependencies), might
be a helpful debugging step.

Another helpful debugging step would be to find a desktop environment that
definitely does have a working polkit agent when installed with systemd
(perhaps LXDE), and try installing that same desktop environment with
sysvinit/elogind for an apples-to-apples comparison.

> However, all 'desktop' polkit integration appears non-functional
> (reboot/hibernate/shutdown in lightdm an xfce4, pcscd mount etc...).  The DBus
> error is InteractiveAuthorizationRequired.

The documented meaning of that error is: the message requesting a
privileged action did not have the flag
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION set, but something
(in practice polkit) had a policy that would have required it to carry
out interactive authorization, so the D-Bus service (lightdm or whatever)
is making the request fail in order to get a result back to the caller
promptly. The intention is that callers set
DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION if they are willing
to wait, potentially for several minutes, for a user to respond to a
prompt.

However, it's possible that polkitd or some other relevant component
might be reusing that error code to indicate "my policy told me to
carry out interactive prompting, but I can't find an agent to do the
actual prompting, so I'm denying the request".

    smcv

[toc] | [prev] | [next] | [standalone]

#1224457

From	tito <farmatito@tiscali.it>
Date	2024-12-17 14:50 +0100
Message-ID	<JUG7v-ef4-3@gated-at.bofh.it>
In reply to	#1224433

On Tue, 17 Dec 2024 10:53:39 +0000
Simon McVittie <smcv@debian.org> wrote:

> Context for XFCE and polkitd maintainers (cc'd): a user of XFCE on a
> sysvinit/elogind system has found that authorizing privileged operations
> via polkit is not working as intended. I'm not at all sure that this is
> actually an elogind problem: it might be a result of XFCE not obviously
> containing a polkit agent (the component that does the actual prompting).
> 
> On Tue, 17 Dec 2024 at 08:24:39 +0000, Mark Hindley wrote:
> > Basic testing of the libpam-elogind stack appears OK: loginctl reports a
> > registered session and 'pkexec id' prompts for a password and reports root.
> 
> An important difference between pkexec and most other polkit clients
> is that pkexec has its own minimal built-in polkit agent, which is
> used as a fallback if the desktop environment has not registered one
> with polkitd. Is the prompt inline on the terminal, or is it a separate
> window? And is the UI the same for the same desktop environment installed
> on a test system (perhaps a VM) that was booted with systemd and has a
> working `systemd --user`?
> 
> If the prompt was inline on the terminal, check that the desktop
> environment is actually launching a polkit agent and registering it with
> polkitd on the D-Bus system bus.
> 
> You can disable the internal agent for debugging by running a command like:
> 
>     pkexec --disable-internal-agent id
> 
> which would be closer to an apples-to-apples comparison with other polkit
> clients. If this fails with the same error message that you have seen for
> other privileged operations, then the problem is that your polkit agent
> is absent or not correctly registered with polkitd.
> 
> Command-line tools like pkexec and flatpak often provide a fallback
> agent on the terminal like this, so that they can be run from a non-GUI
> session. GUI tools essentially never do: they expect to be run in a
> desktop environment session where there is already a working polkit agent.
> 
> I am not familiar with XFCE, but I believe it is meant to include a polkit
> agent of some sort? I can't find a particularly obvious candidate among
> the packages that depend on libpolkit-agent-1-0 or provide
> polkit-1-auth-agent, though. It might be helpful to install a standalone
> polkit agent (perhaps lxpolkit or mate-polkit) and see what happens if you
> run it manually before triggering a privileged operation.
> 
> polkit agents are similar to o.fd.Notification implementations in
> that there is a de facto assumption that any "complete" desktop
> environment should provide one. Some desktop environments include an
> integrated polkit agent that is part of the desktop shell (examples:
> budgie-core, cinnamon, gnome-shell, gnome-flashback, phosh), some have
> a dependency on a desktop-specific standalone agent that is hopefully
> started automatically as part of the desktop environment (examples:
> KDE Plasma/polkit-kde-agent-1, UKUI/ukui-polkit, LXDE/lxpolkit,
> LXQT/lxqt-policykit, MATE/mate-polkit), and environments that are more
> like a kit of parts to build your own desktop environment tend to not
> include one and assume that the user will do their own setup. I had
> hoped that XFCE would be in the first or second categories.
> 
> Historically the polkit agent of last resort was policykit-1-gnome (which
> was the one that was used in GNOME 2), but that one is unmaintained
> upstream (a concerning situation for a security-critical component!) and
> no longer accepts bug reports or merge requests, so the polkit maintainers
> are trying to arrange for it not to be included in trixie (#990271).
> Please do not rely on policykit-1-gnome. If it is the most suitable polkit
> agent for XFCE, then the XFCE team will need to fork it and become the new
> upstream maintainers of the fork.
> 
> If you suspect that systemd vs. not-systemd is part of the problem here:
> some desktop environments use `systemd --user` for part of their session
> startup, and might have different behaviour on less-tested fallback code
> paths (or just not work at all) without it. I know that GNOME and
> KDE Plasma both make some use of `systemd --user` for session startup;
> I don't know whether XFCE does, but that might be another thing to look at.
> An apples-to-apples comparison of two VMs that have the same package
> set and desktop environment, except that one has libpam-systemd (+
> dependencies) and the other has libpam-elogind (+ dependencies), might
> be a helpful debugging step.
> 
> Another helpful debugging step would be to find a desktop environment that
> definitely does have a working polkit agent when installed with systemd
> (perhaps LXDE), and try installing that same desktop environment with
> sysvinit/elogind for an apples-to-apples comparison.
> 
> > However, all 'desktop' polkit integration appears non-functional
> > (reboot/hibernate/shutdown in lightdm an xfce4, pcscd mount etc...).  The DBus
> > error is InteractiveAuthorizationRequired.
> 
> The documented meaning of that error is: the message requesting a
> privileged action did not have the flag
> DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION set, but something
> (in practice polkit) had a policy that would have required it to carry
> out interactive authorization, so the D-Bus service (lightdm or whatever)
> is making the request fail in order to get a result back to the caller
> promptly. The intention is that callers set
> DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION if they are willing
> to wait, potentially for several minutes, for a user to respond to a
> prompt.
> 
> However, it's possible that polkitd or some other relevant component
> might be reusing that error code to indicate "my policy told me to
> carry out interactive prompting, but I can't find an agent to do the
> actual prompting, so I'm denying the request".
> 
>     smcv
> 

Hi,
I'm on a sysvinit/elogind system too and have KDE and xfce4 installed.
I use xfce4 as daily driver and everything works as expected.
I have these polkit stuff installed:

apt list *polkit* | grep installed

gir1.2-polkit-1.0/stable,now 122-3devuan2 amd64 [installed,automatic]
libpolkit-agent-1-0/stable,now 122-3devuan2 amd64 [installed,automatic]
libpolkit-gobject-1-0/stable,now 122-3devuan2 all [installed]
libpolkit-gobject-elogind-1-0/stable,now 122-3devuan2 amd64 [installed]
libpolkit-qt5-1-1/stable,now 0.114.0-2 amd64 [installed,automatic]
polkit-kde-agent-1/stable,now 4:5.27.5-2 amd64 [installed]
polkitd-pkla/stable,now 122-3devuan2 amd64 [installed,automatic]
polkitd/stable,now 122-3devuan2 amd64 [installed,automatic]

when a xfce4 session is running I see:

 ps ax | grep polkit
 5660 ?        Sl     0:00 /usr/lib/polkit-1/polkitd --no-debug
 5829 ?        Sl     0:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1

You can find this polkit agent in the xfce4 -> Settings -> session and startup config
menu but it is not user editable, in fact it is autostarted in:

/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop

--------snip-------
[Desktop Entry]
Name=PolicyKit Authentication Agen
# some more translations here
Exec=/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
Terminal=false
Type=Application
Categories=
NoDisplay=true
OnlyShowIn=XFCE;Unity;X-Cinnamon;
----------------- 

So I presume it is started early in the X startup process
probably by the login manager itself (sddm in my case).

So check if you have this files in place.
Hope this helps.
Ciao
Tito

P.S.:  I recall that I used the Kde polkit agent for sometime
in the past and it mostly did work but had to start it
from user settings autostart.

[toc] | [prev] | [next] | [standalone]

#1224498

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-17 19:00 +0100
Message-ID	<JUK1s-gGb-3@gated-at.bofh.it>
In reply to	#1224457

Hi Tito,

Thanks for sharing your state! (And others for helpful replies - I'm
just answering this one for now.)

On Tue, Dec 17, 2024 at 02:43:36PM +0100, tito wrote:
> Hi,
> I'm on a sysvinit/elogind system too and have KDE and xfce4 installed.
> I use xfce4 as daily driver and everything works as expected.
> I have these polkit stuff installed:
> 
> apt list *polkit* | grep installed
> 
> gir1.2-polkit-1.0/stable,now 122-3devuan2 amd64 [installed,automatic]
> libpolkit-agent-1-0/stable,now 122-3devuan2 amd64 [installed,automatic]
> libpolkit-gobject-1-0/stable,now 122-3devuan2 all [installed]
> libpolkit-gobject-elogind-1-0/stable,now 122-3devuan2 amd64 [installed]
> libpolkit-qt5-1-1/stable,now 0.114.0-2 amd64 [installed,automatic]
> polkit-kde-agent-1/stable,now 4:5.27.5-2 amd64 [installed]
> polkitd-pkla/stable,now 122-3devuan2 amd64 [installed,automatic]
> polkitd/stable,now 122-3devuan2 amd64 [installed,automatic]

I guess you are on stable - I and, presumably the OP, experience this
issue on unstable boxes (and notably not on a box that I upgraded from
stable).

> /etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop

Thanks. I also have this, but notably it is NOT running. This fatal
'warning' appears in session logs and if invoked by hand:

(polkit-gnome-authentication-agent-1:6713): polkit-gnome-1-WARNING **: 17:02:14.853: Unable to determine the session we are in: No session for pid 6713

> So I presume it is started early in the X startup process
> probably by the login manager itself (sddm in my case).

Note that the display manager (lightdm) also does not offer
shutdown options - so that too presumably failed to start an agent.

With the gnome agent deprecated clearly that is an issue in its own right!

I just substitued lxagent. That produces the same error but is actually
still running. Elevation is still not possible.

Thanks,

Andrew

[toc] | [prev] | [next] | [standalone]

#1224460

From	Yves-Alexis Perez <corsac@corsac.net>
Date	2024-12-17 15:10 +0100
Message-ID	<JUGqR-eBk-1@gated-at.bofh.it>
In reply to	#1224433

On Tue, Dec 17, 2024 at 10:53:39AM +0000, Simon McVittie wrote:
> Context for XFCE and polkitd maintainers (cc'd): a user of XFCE on a
> sysvinit/elogind system has found that authorizing privileged operations
> via polkit is not working as intended. I'm not at all sure that this is
> actually an elogind problem: it might be a result of XFCE not obviously
> containing a polkit agent (the component that does the actual prompting).

Hey Simon,

I'm a bit unsure how to reply to your mail because I don't really see
questions. Still providing some bits which might be helpful.
> 
[...]
> 
> I am not familiar with XFCE, but I believe it is meant to include a polkit
> agent of some sort? I can't find a particularly obvious candidate among
> the packages that depend on libpolkit-agent-1-0 or provide
> polkit-1-auth-agent, though. It might be helpful to install a standalone
> polkit agent (perhaps lxpolkit or mate-polkit) and see what happens if you
> run it manually before triggering a privileged operation.

Xfce doesn't provide an authentication agent, as far as I can tell.
There was an xfce-polkit agent tentative
https://github.com/ncopa/xfce-polkit but it didn't really pick up, is
not really maintained and we never packaged it in Debian.
> 
[...]
> 
> Historically the polkit agent of last resort was policykit-1-gnome (which
> was the one that was used in GNOME 2), but that one is unmaintained
> upstream (a concerning situation for a security-critical component!) and
> no longer accepts bug reports or merge requests, so the polkit maintainers
> are trying to arrange for it not to be included in trixie (#990271).
> Please do not rely on policykit-1-gnome. If it is the most suitable polkit
> agent for XFCE, then the XFCE team will need to fork it and become the new
> upstream maintainers of the fork.
> 
On this box I'm apparently indeed using policykit-1-gnome. I think we
might use mate-polkit without too much issues (although it brings
accountsservice as a new dependency).

Regards,
-- 
Yves-Alexis

[toc] | [prev] | [next] | [standalone]

#1224503

From	Simon McVittie <smcv@debian.org>
Date	2024-12-17 20:10 +0100
Message-ID	<JUL7d-hyH-47@gated-at.bofh.it>
In reply to	#1224460

On Tue, 17 Dec 2024 at 14:53:11 +0100, Yves-Alexis Perez wrote:
> I'm a bit unsure how to reply to your mail because I don't really see
> questions.

My question was: does XFCE provide a polkit authentication agent?

And it seems that the answer is in three parts:

1. there is no polkit authentication agent that is part of the XFCE
   project and is packaged in Debian;

2. installing XFCE doesn't really guarantee to provide someone else's
   polkit authentication agent, either;

3. but on a typical end-user system the unmaintained policykit-1-gnome
   might get pulled in by indirect dependencies if you're lucky, and if
   it does, it will get started by the XDG autostart mechanism
   (/etc/xdg/autostart), because XFCE is included in its OnlyShowIn

(One dependency chain that *might* pull in policykit-1-gnome, depending
on how many Recommends have been removed and what order things were
installed in, is
task-xfce-desktop -R-> network-manager-gnome -D-> nm-connection-editor -D-> policykit-1-gnome
where "-R->" represents a Recommends and "-D->" a Depends. There might
be others.)

    smcv

[toc] | [prev] | [next] | [standalone]

#1224512

From	Simon McVittie <smcv@debian.org>
Date	2024-12-17 21:30 +0100
Message-ID	<JUMmB-ifT-5@gated-at.bofh.it>
In reply to	#1224503

On Tue, 17 Dec 2024 at 19:02:19 +0000, Simon McVittie wrote:
> 1. there is no polkit authentication agent that is part of the XFCE
>    project and is packaged in Debian;
> 
> 2. installing XFCE doesn't really guarantee to provide someone else's
>    polkit authentication agent, either;

I've opened a separate bug against the xfce4 metapackage asking for it
to add a dependency on some suitable polkit agent implementation, which
would solve this part of the issue (but would not solve any possible
elogind-specific issue that might also be happening).

    smcv

[toc] | [prev] | [next] | [standalone]

#1224491

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-17 17:50 +0100
Message-ID	<JUIVH-fXN-3@gated-at.bofh.it>
In reply to	#1224433

Simon,

Thanks, that is very useful.

Andrew,

On Tue, Dec 17, 2024 at 10:53:39AM +0000, Simon McVittie wrote:
> check that the desktop environment is actually launching a polkit agent and
> registering it with polkitd on the D-Bus system bus.

I omitted to check for this in the basic steps I gave you.

On my working setup, polkitd is running

test@DebianUnstable:~$ pgrep -a polkitd 
3123 /usr/lib/polkit-1/polkitd --no-debug

and registered on the bus

test@DebianUnstable:~$ busctl|grep -i polkit
:1.62                                              3123 polkitd         polkitd :1.62         -    -       -
org.freedesktop.PolicyKit1 			   3123 polkitd         polkitd :1.62         -    -       -

After killing it

test@DebianUnstable:~$ sudo pkill polkitd
test@DebianUnstable:~$ pgrep -a polkitd 
test@DebianUnstable:~$ busctl|grep -i polkit

it is legacy activated when required

test@DebianUnstable:~$ pkexec id
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/id' as the super user
Authenticating as: Test User,,, (test)
Password: 
==== AUTHENTICATION COMPLETE ====
uid=0(root) gid=0(root) groups=0(root)
test@DebianUnstable:~$ pgrep -a polkitd
3344 /usr/lib/polkit-1/polkitd --no-debug
test@DebianUnstable:~$ busctl|grep -i polkit
:1.68                                              3344 polkitd         polkitd :1.68         -    -       -
org.freedesktop.PolicyKit1                         3344 polkitd         polkitd :1.68         -    -       -

Can you verify polkitd is running correctly and registered?

Thanks

Mark











































> 
> You can disable the internal agent for debugging by running a command like:
> 
>     pkexec --disable-internal-agent id
> 
> which would be closer to an apples-to-apples comparison with other polkit
> clients. If this fails with the same error message that you have seen for
> other privileged operations, then the problem is that your polkit agent
> is absent or not correctly registered with polkitd.
> 
> Command-line tools like pkexec and flatpak often provide a fallback
> agent on the terminal like this, so that they can be run from a non-GUI
> session. GUI tools essentially never do: they expect to be run in a
> desktop environment session where there is already a working polkit agent.
> 
> I am not familiar with XFCE, but I believe it is meant to include a polkit
> agent of some sort? I can't find a particularly obvious candidate among
> the packages that depend on libpolkit-agent-1-0 or provide
> polkit-1-auth-agent, though. It might be helpful to install a standalone
> polkit agent (perhaps lxpolkit or mate-polkit) and see what happens if you
> run it manually before triggering a privileged operation.
> 
> polkit agents are similar to o.fd.Notification implementations in
> that there is a de facto assumption that any "complete" desktop
> environment should provide one. Some desktop environments include an
> integrated polkit agent that is part of the desktop shell (examples:
> budgie-core, cinnamon, gnome-shell, gnome-flashback, phosh), some have
> a dependency on a desktop-specific standalone agent that is hopefully
> started automatically as part of the desktop environment (examples:
> KDE Plasma/polkit-kde-agent-1, UKUI/ukui-polkit, LXDE/lxpolkit,
> LXQT/lxqt-policykit, MATE/mate-polkit), and environments that are more
> like a kit of parts to build your own desktop environment tend to not
> include one and assume that the user will do their own setup. I had
> hoped that XFCE would be in the first or second categories.
> 
> Historically the polkit agent of last resort was policykit-1-gnome (which
> was the one that was used in GNOME 2), but that one is unmaintained
> upstream (a concerning situation for a security-critical component!) and
> no longer accepts bug reports or merge requests, so the polkit maintainers
> are trying to arrange for it not to be included in trixie (#990271).
> Please do not rely on policykit-1-gnome. If it is the most suitable polkit
> agent for XFCE, then the XFCE team will need to fork it and become the new
> upstream maintainers of the fork.
> 
> If you suspect that systemd vs. not-systemd is part of the problem here:
> some desktop environments use `systemd --user` for part of their session
> startup, and might have different behaviour on less-tested fallback code
> paths (or just not work at all) without it. I know that GNOME and
> KDE Plasma both make some use of `systemd --user` for session startup;
> I don't know whether XFCE does, but that might be another thing to look at.
> An apples-to-apples comparison of two VMs that have the same package
> set and desktop environment, except that one has libpam-systemd (+
> dependencies) and the other has libpam-elogind (+ dependencies), might
> be a helpful debugging step.
> 
> Another helpful debugging step would be to find a desktop environment that
> definitely does have a working polkit agent when installed with systemd
> (perhaps LXDE), and try installing that same desktop environment with
> sysvinit/elogind for an apples-to-apples comparison.
> 
> > However, all 'desktop' polkit integration appears non-functional
> > (reboot/hibernate/shutdown in lightdm an xfce4, pcscd mount etc...).  The DBus
> > error is InteractiveAuthorizationRequired.
> 
> The documented meaning of that error is: the message requesting a
> privileged action did not have the flag
> DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION set, but something
> (in practice polkit) had a policy that would have required it to carry
> out interactive authorization, so the D-Bus service (lightdm or whatever)
> is making the request fail in order to get a result back to the caller
> promptly. The intention is that callers set
> DBUS_HEADER_FLAG_ALLOW_INTERACTIVE_AUTHORIZATION if they are willing
> to wait, potentially for several minutes, for a user to respond to a
> prompt.
> 
> However, it's possible that polkitd or some other relevant component
> might be reusing that error code to indicate "my policy told me to
> carry out interactive prompting, but I can't find an agent to do the
> actual prompting, so I'm denying the request".
> 
>     smcv

[toc] | [prev] | [next] | [standalone]

#1224504

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-17 20:20 +0100
Message-ID	<JULgR-hBW-1@gated-at.bofh.it>
In reply to	#1224491

Mark,

On Tue, Dec 17, 2024 at 04:40:42PM +0000, Mark Hindley wrote:
> On Tue, Dec 17, 2024 at 10:53:39AM +0000, Simon McVittie wrote:
> > check that the desktop environment is actually launching a polkit agent and
> > registering it with polkitd on the D-Bus system bus.

Thanks for the extra checks! All pass as per your example.

It looks like the agent (the legacy gnome one) fails to start when
launched by the DE, as does lxagent if substituted:

  Unable to determine the session we are in: No session for pid 24111

Simon,

On Tue, Dec 17, 2024 at 10:53:39AM +0000, Simon McVittie wrote:

> Is the prompt inline on the terminal, or is it a separate
> window?

Inline in terminal.

>   pkexec --disable-internal-agent id

Yields:
  Error executing command as another user: No authentication agent found.

> And is the UI the same for the same desktop environment installed
> on a test system (perhaps a VM) that was booted with systemd and has a
> working `systemd --user`?

I should say so in the case of the installation that was a late
conversion from systemd. I'll convert it back to check.

> Another helpful debugging step would be to find a desktop environment that
> definitely does have a working polkit agent when installed with systemd
> (perhaps LXDE), and try installing that same desktop environment with
> sysvinit/elogind for an apples-to-apples comparison.

Since the DM (lightdm) also doesn't offer these options perhaps we don't
need to consider differences between DEs to root casued this issue?
(Except in so far as we obviously want them to do the right thing too!)

Thanks for your detailed response!

[toc] | [prev] | [next] | [standalone]

#1224508

From	Simon McVittie <smcv@debian.org>
Date	2024-12-17 21:00 +0100
Message-ID	<JULTz-hQz-9@gated-at.bofh.it>
In reply to	#1224504

On Tue, 17 Dec 2024 at 19:15:26 +0000, Andrew Bower wrote:
> It looks like the agent (the legacy gnome one) fails to start when
> launched by the DE, as does lxagent if substituted:
> 
>   Unable to determine the session we are in: No session for pid 24111

This could be an elogind problem. It indicates that
polkit_unix_session_new_for_process_sync() is failing with that error.

"No session for pid %d" probably means that
polkit_unix_session_initable_init() in src:policykit-1
src/polkit/polkitunixsession-systemd.c is failing, which probably means
that:

1. sd_pid_get_session() was not able to associate pid 24111 with a login
   session; and
2. either sd_pid_get_owner_uid() failed to determine the uid of pid 24111,
   or sd_uid_get_display() was unable to find a graphical session for
   that uid

Those are libsystemd functions that communicate with systemd-logind,
or with elogind on elogind systems, so they seem like something that
would be valuable for elogind maintainers to investigate.

    smcv

[toc] | [prev] | [next] | [standalone]

#1224715

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-18 11:20 +0100
Message-ID	<JUZjP-t0p-11@gated-at.bofh.it>
In reply to	#1224508

[ Dropping xfce4 CC ]

Andrew,

On Tue, Dec 17, 2024 at 07:52:10PM +0000, Simon McVittie wrote:
> On Tue, 17 Dec 2024 at 19:15:26 +0000, Andrew Bower wrote:
> > It looks like the agent (the legacy gnome one) fails to start when
> > launched by the DE, as does lxagent if substituted:
> > 
> >   Unable to determine the session we are in: No session for pid 24111
> 
> This could be an elogind problem. It indicates that
> polkit_unix_session_new_for_process_sync() is failing with that error.
> 
> "No session for pid %d" probably means that
> polkit_unix_session_initable_init() in src:policykit-1
> src/polkit/polkitunixsession-systemd.c is failing, which probably means
> that:
> 
> 1. sd_pid_get_session() was not able to associate pid 24111 with a login
>    session; and
> 2. either sd_pid_get_owner_uid() failed to determine the uid of pid 24111,
>    or sd_uid_get_display() was unable to find a graphical session for
>    that uid
> 
> Those are libsystemd functions that communicate with systemd-logind,
> or with elogind on elogind systems, so they seem like something that
> would be valuable for elogind maintainers to investigate.

I don't immediately see significant differences between systemd's and elogind's
cg_pid_get_session() or cg_pid_get_owner_uid(); sd_uid_get_display() is handled
solely within libsystemd0.

Can you please check the runtime data?

How is /sys/fs/cgroup mounted?

test@DebianUnstable:~$ mount|grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)

test@DebianUnstable:~$ loginctl
SESSION  UID USER    SEAT  TTY STATE   IDLE SINCE
      1 1000 test    seat0 -   closing no   -    
      3 1000 test    seat0 -   active  no   -    
     c1  105 lightdm seat0 -   closing no   -    
     c2  105 lightdm seat0 -   closing no   -    

4 sessions listed.

Take the active user session.

test@DebianUnstable:~$ cat /run/systemd/sessions/3
# This is private data. Do not parse.
UID=1000
USER=test
ACTIVE=1
IS_DISPLAY=1
STATE=active
REMOTE=0
TYPE=x11
ORIGINAL_TYPE=x11
CLASS=user
FIFO=/run/systemd/sessions/3.ref
SEAT=seat0
DISPLAY=:0
SERVICE=lightdm
DESKTOP=xfce
VTNR=7
LEADER=2063
AUDIT=3
REALTIME=1734375305872153
MONOTONIC=4650196364

Verify the DISPLAY matches

test@DebianUnstable:~$ echo $DISPLAY
:0.0

Take the LEADER pid.

test@DebianUnstable:~$ cat /proc/2063/cgroup 
0::/user.slice/user-1000.slice/session-3.scope

Verify that path exists beneath /sys/fs/cgroup

test@DebianUnstable:~$ ls -l /sys/fs/cgroup/user.slice/user-1000.slice/session-3.scope/
total 0
-r--r--r-- 1 root root 0 Dec 18 09:35 cgroup.controllers
-r--r--r-- 1 root root 0 Dec 18 09:35 cgroup.events
-rw-r--r-- 1 root root 0 Dec 18 09:35 cgroup.max.depth
-rw-r--r-- 1 root root 0 Dec 18 09:35 cgroup.max.descendants
-rw-r--r-- 1 root root 0 Dec 18 09:35 cgroup.procs
-r--r--r-- 1 root root 0 Dec 18 09:35 cgroup.stat
-rw-r--r-- 1 root root 0 Dec 18 09:35 cgroup.subtree_control
-rw-r--r-- 1 root root 0 Dec 18 09:35 cgroup.threads
-rw-r--r-- 1 root root 0 Dec 18 09:35 cgroup.type
-r--r--r-- 1 root root 0 Dec 18 09:35 cpu.stat

If none of this shows any significant discrepancy, I think you will need to build elogind
with debugging. Having downloaded the source, add

 -Ddebug-extra=elogind

to CONFFLAGS in debian/rules and then build.

Thanks.

Mark

[toc] | [prev] | [next] | [standalone]

#1224763

From	Andrew Bower <andrew@bower.uk>
Date	2024-12-18 19:40 +0100
Message-ID	<JV77H-yTM-7@gated-at.bofh.it>
In reply to	#1224715

Control: tags 1076728 - moreinfo unreproducible

Hi Mark,

On Wed, Dec 18, 2024 at 10:10:03AM +0000, Mark Hindley wrote:
> Can you please check the runtime data?
> 
> How is /sys/fs/cgroup mounted?

Differently from yours...

$ mount|grep cgroup
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755,inode64)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)
cgroup on /sys/fs/cgroup/elogind type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/libexec/elogind-cgroups-agent,name=elogind)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,relatime,net_cls)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_prio type cgroup (rw,relatime,net_prio)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,relatime,hugetlb)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,relatime,pids)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,relatime,rdma)
cgroup on /sys/fs/cgroup/misc type cgroup (rw,relatime,misc)

These mounts are set up by the docker initscript. Disabling the docker
initscript and rebooting results in full functionality: shutdown
buttons, CUPS admin, smartcard access, GUI prompt for pkexec id.

In this case the only difference with the diagnostic output is I have
more content under the scope directory under sysfs.

So a good find with that diagnostic request, thank you Mark!

I think we can therefore move this bug to docker.io?

For completeness, here is the rest of the diagnostic output in the
failing situation:

$ loginctl
SESSION  UID USER    SEAT  TTY STATE   IDLE SINCE
      1 1000 andy    seat0 -   active  no   -    
     c1  108 lightdm seat0 -   closing no   -    

2 sessions listed.
$ cat /run/systemd/sessions/1
# This is private data. Do not parse.
UID=1000
USER=andy
ACTIVE=1
IS_DISPLAY=1
STATE=active
REMOTE=0
TYPE=x11
ORIGINAL_TYPE=x11
CLASS=user
FIFO=/run/systemd/sessions/1.ref
SEAT=seat0
DISPLAY=:0
SERVICE=lightdm
DESKTOP=lightdm-xsession
VTNR=7
LEADER=3085
AUDIT=1
REALTIME=1734543482585228
MONOTONIC=24608270
$ echo $DISPLAY
:0.0
$ cat /proc/3085/cgroup
13:misc:/
12:rdma:/
11:pids:/
10:hugetlb:/
9:net_prio:/
8:perf_event:/
7:net_cls:/
6:freezer:/
5:devices:/
4:name=elogind:/user.slice/user-1000.slice/session-1.scope

And the relevant location is:

/sys/fs/cgroup/elogind/user.slice/user-108.slice/session-c1.scope

[toc] | [prev] | [next] | [standalone]

#1224767

From	Mark Hindley <mark@hindley.org.uk>
Date	2024-12-18 20:10 +0100
Message-ID	<JV7AJ-znr-3@gated-at.bofh.it>
In reply to	#1224763

Control: retitle -1 elogind: use of cgroups conflicts with docker.io

On Wed, Dec 18, 2024 at 06:29:32PM +0000, Andrew Bower wrote:
> Control: tags 1076728 - moreinfo unreproducible
> 
> Hi Mark,
> 
> On Wed, Dec 18, 2024 at 10:10:03AM +0000, Mark Hindley wrote:
> > Can you please check the runtime data?
> > 
> > How is /sys/fs/cgroup mounted?
> 
> Differently from yours...

I am pleased we have found something

Lorenzo, you reported this originally. Can you confirm you have docker.io
installed and it is the same issue?

> I think we can therefore move this bug to docker.io?

Maybe. I am at (or probably beyond) my area of expertise. At the moment I am
unsure if elogind ought to be using its own cgroups namespace or if docker.io is
behaving badly here. Time for some reading....

Mark

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

Bug#1076728: elogind: privileged operation with polkit fails

Contents

#1224024 — Bug#1076728: elogind: privileged operation with polkit fails

#1224030

#1224032

#1224284

#1224357

#1224410

#1224387

#1224413

#1224433

#1224457

#1224498

#1224460

#1224503

#1224512

#1224491

#1224504

#1224508

#1224715

#1224763

#1224767