Package: upower Version: 0.9.20-2 Severity: normal Dear Maintainer,
as I reported in bug Bug#717554: systemd: authentification is required for hibernating while other users are logged in http://bugs.debian.org/717554 already, since upgrade to systemd 204-1 on trying to hibernate I get on selecting hibernation (suspend-to-disk) from Kickoff KDE menu the screen is locked as usual but no hibernation takes place. When I unlock the screen again, I see a window: Authentification is required for hibernating the system while other users are logged in. Well I did not manually have two logins open, but dirmngr seems to open one: merkaba:~> apt-show-versions | grep dirmngr dirmngr:amd64/sid 1.1.0-3 uptodate merkaba:~> loginctl SESSION UID USER SEAT c1 120 dirmngr c2 1000 martin seat0 2 sessions listed. merkaba:~> ck-list-sessions Session5: unix-user = '0' realname = 'root' seat = 'Seat1' session-type = '' active = FALSE x11-display = '' x11-display-device = '' display-device = '/dev/pts/0' remote-host-name = '' is-local = TRUE on-since = '2013-07-22T14:09:31.717064Z' login-session-id = '4294967295' Session2: unix-user = '1000' realname = 'Martin Steigerwald' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2013-07-22T11:25:40.817811Z' login-session-id = '4294967295' I want to get rid of this dialog for several reasons: 1) I just said hibernate, I was authentificated as my other, just do it! As before, with older systemd or as with insserv. From a user point of view this is a regression. 2) This is a laptop. I am the *only* one using it at that time. So there is exactly *one* human user (and one seat). So if I say hibernate, do it! Basta. 3) KDE locks the screen and displays that polkit window at the same time. Thus I cannot enter my sudo password at the polkit window without unlocking the screen. But if I do so and do not press Ctrl-Alt-L to lock the screen again quickly enough, the machine hibernates without a locked desktop! I am willing to report this as separate important issue with some KDE package. But I do think this is a real policy issue, see below. I tried to work-around this by applying Michael´s hint from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717554#32 which points to: https://wiki.archlinux.org/index.php/PolicyKit#Suspend_and_hibernate So I added: merkaba:~> cat /etc/polkit-1/localauthority/50-local.d/org.freedesktop.upower.pkla [Suspend/hibernate permissions] Identity=unix-group:sudo Action=org.freedesktop.upower.hibernate;org.freedesktop.upower.suspend ResultAny=yes ResultInactive=yes ResultActive=yes (I was certainly not willing to add another unix group such as power for something that is supposed just user friendly out of the box). Well but this didn´t work either, the polkit window still appears. Anyhow I think this is better fixed policy wise. My reasons are: - if systemd 204-1 or later will become standard init in Debian all KDE users who have KDEPIM installed will face that usability issue. - its a laptop, its one real human user. Displaying that window just does not make any sense usability wise to me. I do not like software trying to be more intelligent that I am. My suggestion is: Rework the policy to be based on seat. As I understand from Lennart´s blog posts or somewhere else a seat is a combination of display, keyboard, mouse and so on to be used by one user. With multi seat with mutiple displays, keyboards and mouses more than one user can work simulatenously on one machine. Then that polkit window makes at least *some* sense. But with just one user I think usability wise its fair game to hibernate if he tolds so. Heck even with two X.org sessions as I use sometimes, one for work and one for private stuff, as long as its just me, don´t ask. I expect these two X sessions to be on same seat, so if that holds true, which I can test for you if you want, a seat based rule may just work fine. This may even point back to systemd, ck-list-sessions reports both sessions to be on the *same* seat 1, whereas loginctl does report dirmngr to be on no seat and my desktop session to be on seat 0. However its solved technically, maybe even in dirmngr package, its good *not* to ask user in that case. If that is not the suitable package to report the bug to, please advice on where to reassign the bug or where to report, instead of just closing it. I bet Michael, you are reading this, after you closed 717554 without the problem having been dealt with in a way that IMHO makes sense usability wise, I looked as to where the default policy comes from and according to martin@merkaba:~> dpkg -S /usr/share/polkit-1/actions/org.freedesktop.upower.policy upower: /usr/share/polkit-1/actions/org.freedesktop.upower.policy its upower. I do not think that many users will like to put up with the current behavior. IMO it just does not make *any* sense usability wise. Any user who´d have kdepim installed would face that issue, as this package depends on dirmngr. Thanks, Martin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-rc2-tp520+ (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages upower depends on: ii dbus 1.6.12-1 ii libc6 2.17-7 ii libdbus-1-3 1.6.12-1 ii libdbus-glib-1-2 0.100.2-1 ii libglib2.0-0 2.36.3-3 ii libgudev-1.0-0 175-7.2 ii libimobiledevice2 1.1.1-4 ii libplist1 1.8-2 ii libpolkit-gobject-1-0 0.105-3 ii libupower-glib1 0.9.20-2 ii libusb-1.0-0 2:1.0.16-1 ii pm-utils 1.4.1-11 ii udev 175-7.2 Versions of packages upower recommends: ii policykit-1 0.105-3 upower suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
