Re: systemd-fsck?
Am Samstag, 10. Mai 2014, 21:36:42 schrieb Laurent Bigonville:
> Le Sat, 10 May 2014 19:13:01 +0200,
> Matthias Urlichs <matthias@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
Reply to: