On Sat, Aug 9, 2014 at 4:04 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > Chris Angelico wrote: > >> On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano >> <steve+comp.lang.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list