[KDE4] what component does the screenlocking?

[Duncan]

René J.V. Bertin posted on Tue, 28 Feb 2017 23:16:42 +0100 as excerpted:

> Please allow me a few follow-up questions
> 
> Given that apparently the KDE4 screensaving/locking mechanism is too old
> to work correctly with whatever component is now too new:
> 
> 1) can I prevent locking entirely, including at suspend/wake? I thought
> I'd seen an option that controls this in systemsettings but cannot seem
> to find it anymore. I tried a wrapper script that filters out
> --immediateLock but it seems that approach has been made impossible.

It is/was possible, as back in kde4 I did it.  But that's some time ago 
so my memory of the details is fading, and I am and was running gentoo, 
which typically gives the end-user-admin rather more choice in package 
feature-related-dependencies and other configuration than most distros, 
so the degree to which my rather odd config then if I do remember it 
correctly applies to your situation now, isn't known.

What I do remember is that the kde4 and kde5 screen-locking mechanisms 
are quite different.  I don't run or indeed have installed a *DM 
graphical login manager of any kind, preferring to do a text-based login 
and (effectively) run startx with a kde x-session setup to run.

Without kdm or similar installed, kde4/plasma4 didn't have a greeter 
available and I had to be careful not to lock the screen, etc, because 
there was no way to unlock it as I had no greeter.

Plasma5, by contrast, appears to have its own screen-unlock greeter, and 
the lack of *dm doesn't matter for it -- I can lock the screen and 
hitting a key or wiggling the mouse will bring up the unlock dialog just 
fine.  (Tho it can be noted that earlier 5.x versions, I'm running live-
git of frameworks/plasma/apps now and the problem is fixed, appeared to 
have some sort of issue with the radeon freedomware drivers, such that 
some combination of screen blanking/powerdown/locking, I never quite 
figured out exactly which, would cause X to go unresponsive.)

So back on kde4 I *had* to ensure that the screenlocker didn't trigger, 
because that meant killing X and the existing kde4 session (via the 
kernel's magic-srq-K or switching VTs and killing it from there) in 
ordered to get back to a situation where I could run startx and start a 
new one, since I couldn't get back into the old one.

So yes, it's definitely /possible/, as that's the only way it would work 
in kde4, for me.

Of course I also have policykit and friends options turned off and the 
associated plumbing not even installed, which means suspend/hibernate via 
KDE gui doesn't work as it can't get authorization.  However, I've never 
had problems triggering them via my own scripts and (appropriately 
configured) sudo, and resuming doesn't return me to a screenlock, either.

In terms of kde config, IIRC the main thing was setting the screen saver 
stuff not to lock, and turning off the (manual) lock option display where 
possible, or simply staying away from it where I couldn't figure out how 
to turn it off, since I knew locking would effective mean killing the kde 
session, and I could do that more effectively by simply logging out of 
the session and returning to a text console prompt.

> 2) can KF5 kscreenlocker function outside of a Plasma5 session?
> kscreenlocker_greet complains about loading a wallpaper (probably just a
> warning), but it doesn't display an unlocking dialog which for all
> practical purposes is the same as a dysfunctional dialog. This is true
> also when I run KWin5 (kwin_x11), as if it also doesn't work properly
> for some related reason.

I /believe/ the kf5 screenlocker is plasma5 specific, for the reason 
described above (it's now a plasma5 desktop component and expects to work 
as such, not using the *dm greeter component as in kde4).

But I'm not a dev, just a user, and that's only my /belief/.

> Which begs the question:
> 3) suppose something like this happens on a Plasma5 desktop, what
> backdoors are there to unlock the session without killing it, from a
> virtual console?

Any such backdoors would be considered security bugs, and thus 
exterminated.  (To the extent possible with X, of course.)

One of the problems with X is that it simply wasn't designed to be run in 
an untrusted user environment, the reason any X-based app can see the 
input to any other, including passwords, etc, and enforcing input grabs 
to truly enforce authentication before X-session unlocking has always 
been a security challenge as a result.  Wayland, however, is designed to 
be far more security aware, and eliminates these sorts of issues to a 
large degree, to the point that the problems are actually then in 
allowing such cross-application input spying where actually desired.  
Basically, the compositor, kwin-wayland in plasma's case, is the only 
application allowed to spy on the input of other wayland apps' input 
streams, which means the compositor is the only app that can do global 
wayland hotkeys, for instance.  Unless of course it specifically passes 
on that information to some other component, and from the development 
discussion I've read, kwin-wayland is by design extremely particular 
about which other apps it will pass that information on to, for security 
reasons.  IOW, expect the number of global hotkey apps available on 
wayland to be far smaller than the number of corresponding apps for X, 
and expect restrictions on the ones that can be run with specific 
compositors, as well.  All for security reasons.

Because a primary focus of plasma5 is porting to wayland, with current 
status being runnable but with various quirks still being polished out so 
it's not yet recommended for ordinary users, expect later plasma5 
versions to work with both xorg and wayland, of course with the latter 
supporting wayland's rather better security environment and other modern 
protocol benefits, tho likely at the cost of somewhat limited flexibility 
on both sides as compatibility with the earlier X environment is 
maintained.  Presumably with plasma6 (entirely my own predictions as a 
user, tho I am following git commits), if the wayland transition 
continues native wayland will likely be the primary focus, tho X may well 
still be supported, possibly as legacy, and projecting further out, 
perhaps plasma7 will be native-wayland-only, tho still with the 
possibility of running rootless X-nested sessions for legacy X apps.

.....

Meanwhile, somewhat OT usage note FYI: "Begs the question", with a 
question following, despite being arguably logical current usage (which I 
fully support and use myself, tho usually with a note indicating I'm 
doing it deliberately, so don't take this wrong), is considered by many 
to be improper usage.

The term has a long history, tracing back thru Latin (petitio principii, 
asking for the starting point, assuming the premise) and Greek (asking 
for the initial thing), where it originally referred to (more or less) 
circular logic.  To "beg the question" meant that the original question 
or proposition of logic was not supported by what followed, since that 
ultimately simply resulted in either a restatement of the original 
question/proposition instead of answering/supporting/proving it (directly 
circular logic), or assumed the truth of a second question/proposition 
that hadn't been adequately demonstrated itself (not directly circular, 
more complex).

The term in that usage form continues to be seen today, particularly in 
the legal and logic communities, where it can often be spotted standing 
alone (without a following question) in reply to some often convoluted 
logic, pointing out that it doesn't support or prove the original 
proposal at all, but rather only leads back to it or a related proposal 
that hasn't been demonstrated to be true.

However, that original and still somewhat common in some communities 
usage has been overtaken in the wider general population by the more 
popular "That begs the question: New question following from old" usage, 
as seen above.  Certainly, this usage seems logical enough to me, as 
"strongly suggests as a followup", or "begs that the question be asked", 
a more literal read of the individual words themselves.  But it's not the 
original/historical meaning, and some people will certainly look down on 
you if you use it in this way, despite its current general popularity 
used this way.

Rule of thumb: As I've touched on in passing above, if "begs the 
question" can stand alone, without a following question, that's likely to 
be the historical meaning as still used in philosophy, logic, and legal.  
If "begs the question" must be followed by a question to make sense, it's 
likely to be the arguably now more common in general but still quite 
controversial meaning.

Which is why I usually footnote (or explain in parentheses) usage (either 
way) of my own, with something like: "(Yes, I'm familiar with the meaning 
related to circular logic, but deliberately choose to use and support 
this now more popular usage myself.)"  The idea being that while they may 
still disagree with my usage, it's quite obvious that I actually know the 
usage they consider "proper", and that I made the choice to use it in 
this way entirely deliberately.  Then I usually include references:

https://en.wikipedia.org/wiki/Begging_the_question

http://begthequestion.info/

https://public.wsu.edu/~brians/errors/begs.html

I actually subscribe to the language-log feed, having discovered it 
myself while looking up another phrase (toe the line, /not/ tow the line, 
which I had thought), and found their approach and many of the articles 
and discussion to my liking.  Their article on "begs the question" is 
both historically detailed and reasonable, with a nice discussion 
following, tho as detailed above I've chosen for my own personal usage 
something a bit different than their recommendation in point #4:

http://languagelog.ldc.upenn.edu/nll/?p=2290

And finally, the related google, with its many many more links:

https://www.google.com/search?q=begs+the+question

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman