Keep one GUI always on TOP while python code is running

[Chris Angelico]

On Sat, Aug 9, 2014 at 4:04 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Chris Angelico wrote:
>
>> On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano
>> <steve+comp.lang.python at pearwood.info> wrote:
>>> Chris Angelico wrote:
>>>
>>>> Yeah; like I said, "Don't" is the short answer. There will be
>>>> exceptions, some extremely rare situations when system modality is
>>>> correct; but fundamentally, it's impossible to use GUI software to
>>>> control what a person does with a computer
>>>
>>> There are exceptions, but it's impossible? Impossible except for the
>>> exceptions, I presume :-P
>>
>> There are exceptions to the rule "you shouldn't use system modal
>> windows". It is, however, fundamentally impossible for GUI software to
>> completely control what the person does - system modality is defined
>> only to the extent of the GUI.
>
> *Fundamentally* impossible? You've never used classic Mac OS, I take it. Or
> a non-jail-broken iPhone.
>
> There is nothing *fundamental* that says that a GUI interface is necessarily
> a second-class interface, or that a non-GUI interface is always available.

What I mean is that GUI software can't control the entire computer.
It's impossible for a system-modal flag to prevent access to non-GUI
parts of the computer. Now, if there happen to be none of them (that
you're aware of - certain OSes are rife with unexpected backdoors),
then for all practical purposes, it's controlling the whole computer -
but technically it still isn't.

> You're assuming that there are any virtual terminals running on the system,
> which is not a given. Windows doesn't have them at all. Even in Linux, they
> can be turned off(?) or at least access to them disabled. For that matter,
> you're assuming the machine has a keyboard attached. Have you never seen a
> machine running in kiosk mode with only a touchscreen or trackball?
>
> http://wiki.tldp.org/Kiosk-HOWTO

This is what I was saying about the system being so locked down
already that there's no point going system modal. If you can't invoke
other programs, what's it matter if you could switch to other running
programs? So system modality is still pointless on a kiosk.

>>> Does that work when xscreensaver or equivalent has locked the system? If
>>> so, that's a security vulnerability.
>>
>> Absolutely it works! However, what you get to is a terminal with a
>> login prompt.
>
> I don't think so. I think you get a terminal which may or may not be already
> logged in. Hence the security vulnerability: if you leave a virtual
> terminal logged in, then locking the X terminal alone via xscreensaver is
> useless.
>
> I haven't tried it with xscreensaver itself, but I've just tried it with
> whatever screensaver KDE under Centos uses, and sure enough, it locks the X
> session but allows access to any virtual terminals that happen to already
> be logged in with no authentication needed.

Oh, sorry. I thought you were talking about the "oops you got around
my security" problem. If you leave something logged in, that's a
security vulnerability; whether that's on a VT or in a web browser
tab, someone (you or someone else) can then use it. As far as I'm
concerned, the vulnerability has nothing to do with a locked GUI. If
you're trying to ensure that someone can't get around your program,
you have to make sure there's no available logins.

> [...]
>>> * exam software;
>>
>> This is what I'm dubious about. Since you can always log in via some
>> other method,
>
> Always? You're saying it is impossible to disable telnet and ssh? Or unplug
> the network cable?

I'm assuming here that the student has some control of the computer
the software's being run on. If the student has absolutely no control
over the computer, then it's the kiosk situation; there's no point
locking the GUI because you'll already have locked everything else.
What you're basically saying is "Hey look, I have a perfect lock on my
front door - backed up by a moat full of angry crocodiles". The crocs
make the lock superfluous.

>> or brute-force something (eg replace one of the system
>> accessibility programs with your own tool),
>
> And how am I supposed to do that, from the exam software itself, without
> access to a shell?

Again, this would be something you'd do beforehand, making use of some
measure of control over the computer. If you can't do anything like
that, it's kiosk mode.

I'm thinking here of the time I had a Windows 7 VM that I'd forgotten
the password to. The solution? Boot a rescue disk (I could probably
have done this with a Linux live CD and an ntfs mount), copy cmd.exe
over the top of some accessibility program (backing it up first), and
reboot. The same can be done with Linux; if you can boot your own
media, you can change anything and give yourself access (put yourself
in sudoers, give yourself some groups, create a setuid root shell,
etc, etc, etc). So the *only* way to prevent access to a physical
machine is to prevent *all* access. And at that point, any lesser
control is utterly superfluous.

> We're getting further and further from
> the OP's question, which should be interpreted in the most reasonable
> manner, not the least reasonable:
>
> - he probably only cares about blocking access to the rest of the
>   GUI environment, not virtual terminals (assuming he is even using
>   a system with virtual terminals);

In that case, a (possibly maximized) always-on-top window is probably
all he needs. Which is why that was my very first response to him.

> - or he's trying to build a kiosk application.

In that case, he needs to learn a lot about how to build a kiosk, and
it's way WAY beyond the scope of python-list.

> It is unreasonable to interpret his comment "user cant [sic] do any other
> operation" so broadly that we have to care about (e.g.):
>
> - ssh'ing into the computer from another machine;
>
> - rebooting into single user mode;
>
> - walking away from the computer to do something else.
>
> All those things can be solved (e.g. by turning off the ssh daemon, or
> blocking access at the firewall, using a custom BIOS, and chaining the user
> to the computer), but likely not by the GUI toolkit itself.

Definitely. I don't think there's a wxpython flag
wx.CHAIN_USER_TO_CHAIR. That said, though: it is conceivable to have
students use their own computers for exams, while under approximate
observation by a human. That would prevent them from using external
devices or paper notes, but would make all the rest of this thread
exactly correct. And that's what I'm saying is fundamentally
impossible; if the students have any prior access to the computers,
they can get around the problem - and if they have no prior access (or
they get HD wiped before the exam), then there's nothing to access
anyway, and thus no problem. (Presumably, anyone who would go to the
effort of wiping the drives to keep notes away will also isolate them
from the network.)

Personally, though, I think the whole concept of exams is pretty
pointless. I heard somewhere that the final qualifying test for
certain Cisco certifications is to be put in a room with a router that
someone's broken in some way, and told "You have X minutes. Fix it.".
No need to lock out a GUI, this is absolutely accurate to real life.
Of course, it's a bit hard to put someone in a room with allgebra and
say "I've broken something. Fix it."... :)

ChrisA