Am Samstag, 10. Mai 2014, 21:36:42 schrieb Laurent Bigonville: > Le Sat, 10 May 2014 19:13:01 +0200, > Matthias Urlichs <matth...@urlichs.de> a écrit : > > Hi, > > [...] > > > > Telling "Go away, the bug is elsewhere" is just not an approbiate > > > reaction for developers of a low level system component. > > > > For the record: I do not disagree with this statement. > > I think there are some misunderstanding here. > > The initial bugreport really sounded like a feature request / changes > of behavior not an actual bug. > > And IMHO pointing the user to the documentation so the user can change > it himself was perfectly correct.
I tried this and it just didn´t work, which I reported as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727645#50 But got ignored. I think I still would like to have this. As it I still get a password prompt if trying to hibernate with two KDE sessions on which share a single seat. One private one and one work one. I just don´t get it where on a single seat system being asked for a password on hibernate could make even make remote sense. At least not as a *default* case. I probably would understand it for shutting down… but all that will happen is that processes are put to sleep. Well network connection may break. But honestly: Did you ever see a laptop with one seat being used by mutiple users that would not know and talk to each other when to hibernate the machine? And how would entering a password in that case be helpful to change their behaviour if they do not? If they one who triggers the hibernate doesn´t care he or she will enter the password and be done with it. I do think this is such a rare corner case that it does not make even remote sense to have such behaviour as a default. With all the implications this has: Cause in current behaviour of Plasma desktop this creates a security problem. First the screenlocker locks the screen, then the dialog to ask the password opens up. I can unlock the screen, but if I enter the password, it hibernates almost immediately with the screen unlocked unless I have the chance to lock it before by pressing Ctrl-Alt-L quickly enough. Granted I would see this as a bug in how Plasma desktop handles things. But again: It is changing the default behaviour without looking at what will break. I think this behaviour make as much sense as asking for a root password for setting up a printer as Linus´ daughter was asked once. (I know this can be configured by group memberships in Debian.) I strongly dislike that such a kind of behaviour is being pushed as a default onto the users on a single seat system. It is unintuitive, regresses over the behaviour that was there for the last decades, and in its current form even introduces a security problem. Do you expect all users that get annoyed by it to change their PolicyKit configuration? So yes, I agree fixing the su in dirmngr. But I don´t think this is sufficient and propose not asking for hibernate password on a single seat system. Especially as you are not asked for a password on suspend either. I can suspend without a password just fine. Really: Can it get any more inconsistent, unintuitive and annoying? Thus I don´t agree with you merging all the reported bugs into dirmngr fixing the init script in it in my eyes is just fixing part of the reported problem. > Looking at the original bug again, it seems that there were actually > several issues. The bug with dirmngr creating a logind session and the > fact that pam_loginuid was not properly set (login-session-id set to > MAX_INT). It was for a reason I reported several bugs, as I after the feedback I got was not sure against which component to report it on. > The former bug will be fixed soon (I've pushed a NMU to the delayed/3 > queue) and the later should have been fixed in KDM for quite sometimes > now. Thank you very much. I appreciate it. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9722989.GBrqMUSZlJ@merkaba
