Re: Suspend/X workaround: security issue

[Heather <star@betelgeuse.starshine.org>]

> Hugo van der Merwe wrote:
> 
> > Great, so I go and write an executable file in /etc/apm/event.d/01x_bugfix
> > containing:
> 
> [script omitted]
> 
> > This strikes me as a security risk
> 
> A mild one, but yes.  It strikes me that a better solution would be to
> figure out why suspend causes problems with X.  I know it doesn't on
> most machines -- works great on mine.

At the very least, put the file in /var/lock or in /var/run.  (You're "locked"
in suspend, or "suspend is running", whichever makes better sense to you.)
These aren't publicly scribble-able, at least reducing the risk.
 
> If you really need a more secure approach, maybe you can set up some
> sort of daemon that can be prodded to remember the vt on suspend, and
> can keep the # in memory, and regurgitate it on resume.  But that seems
> like an awful lot of work.  Possibly more than debugging the X vs.
> suspend conflicts.
 
Ah, but it -is- possible to ask what vt you were on, and you can simply
stash that number in your "lock". (brain fuzzy at this moment of the morning,
I'm thinking 'fgconsole' but can't recall if that's the rh version - I do this
under both flavors of system.) Then on suspend

	chvt 12

(or some other "safe" console - 12 is where I keep system logs onscreen) 
On resume, 

	chvt $(cat /var/lock/suspconsole) && rm /var/lock/suspconsole

Anyways, mostly working is better than not.

-* Heather Stern * star@starshine.org *-