[ltp] vlock + suspend to RAM fails

[Felix E. Klee]

On Sat, 21 Jan 2006 15:47:36 +0100, "Daniel Maier" <nusse@teamidiot.de>
said:
> > Can anyone reproduce the problem?  What may be the cause?
> According to some smart guy, it is known and he also made a fix.
> http://www.formorer.de/~formorer/lock

Great.  Thanks for the link!

And, by looking at the skript, I also learned something new concerning
shell programming: "set -e" - very valuable!

> 15:43 <@formorer> und 63 ist das zauberwort "and 63 is the magic key"

Yeah, this seems to be the trick.  May I ask what IRC channel on which
server you were chatting on?  I'm interested in channels where one can
discuss Thinkpad / laptop related issues.

Anyway, my current suspend to RAM script:

  #!/bin/sh
  
  # Puts the system into ACPI mode S3 (suspend to RAM), unless the first
  # parameter is "on_closed_lid" and the lid is open.
  
  # Sample ACPI deamon event file for executing this script (the "&" is
  # necessary so that the deamon will call the script if the event is
  # triggered several times in a row, e.g. when the lid has been opened,
  # and suddenly needs to be closed again, before the password can be 
  # entered - happens sometimes at the railway station):
  
  #   event=button/lid.*
  #   action=/usr/local/lib/t41-tools/sleep on_closed_lid &
  
  # Note that sometimes after waking up, the password prompt is not
  # properly displayed.  In this case: Just type a couple of characters
  # and hit return.
  
  # There are no checks preventing vlock from getting called twice: I'm
  # worried about race conditions weakening security.
  
  # Felix E. Klee <felix.klee@inka.de>
  
  [ $1 = "on_closed_lid" ] && \
      grep -q open /proc/acpi/button/lid/LID/state && exit 0
  
  sync # For the case that the system does not wake up again
  
  echo mem > /sys/power/state
  openvt -f -c 63 -w -s -- su - felix -c "/usr/bin/vlock -a 2>&1 |
  logger"

Now, I only wonder what will happen if the system is under high load
when
waking up: In this case the consoles may stay unlocked for a
considerable 
amount of time, giving an intruder the possibility to read what's on 
screen, or perhaps even to get control of the system.

Any idea how to avoid that?
-- 
Felix E. Klee