Keep one GUI always on TOP while python code is running

[Steven D'Aprano]

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.


>>> (for instance, on all my
>>> Linux systems, I can hit Ctrl-Alt-F1 to switch away from the GUI
>>> altogether).

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


>> 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.


[...]
>> * 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?

But really, now we're getting silly. No, exam software isn't going to
prevent you from ssh'ing into the computer from another computer, assuming
ssh is allowed. Nor is it going to prevent you from using another computer,
getting answers from handwritten notes or books, or asking somebody to help
you. That's hardly the point.


> 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?


> it's impossible for the 
> software to stop you from running something else. And if the computer
> you're doing this on is so locked down that you can't pull up your
> notes in some other app, it may as well simply be so locked down that
> you can't get your notes onto that computer in the first place.

Um, yes? Although not necessarily. 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);

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

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.


-- 
Steven