Re: Bigger annoyance with locking.

[Dan Mahoney, System Admin]

On Thu, 13 Nov 2008, Trent W. Buck wrote:

> Micah Cowan <address@hidden> writes:
>
> > Dan Mahoney, System Admin wrote:
> > > According to the manpage, screen calls /bin/lock or whatnot -- there's
> > > no way through .screenrc to change this (why?)...and yet the output of a
> > > locked screen looks significantly different from when I use lock alone.
> >
> > It uses whatever's in $LOCKPRG. Looking at the current code, it seems
> > the message about /usr/bin/lock and /usr/local/lck is outdated: screen
> > appears to always use the builtin when $LOCKPRG isn't specified (this
> > may be due to known bugs in common lock implementations?). Anyway, make
> > sure $LOCKPRG is set appropriately in the foreground screen's environment.

Okay, then two questions:

Since I have NO IDEA about programming viable non-character-escapable 
terminal locking programs...

1) Are there any more useful console lockers than /bin/lock?  In looking 
through bsd's ports, I found "tss" which looks a bit useful, but requires 
setuid to read the password file (which gets me back where I started!) -- 
my password's not there!

2) What's the logic in not letting this be set via screenrc -- why is this 
literally one of the only options to use a nonstandard environment app? 
What other program (I just did a rudimentary google) makes use of this 
variable?  Are there other shells that have the ability to call this on 
idle?

A typical use of using environment variables for this is when more than 
one standardized program needs to pass variables to others.  For example, 
PAGER, EDITOR, TERM...if there's only one program that uses this, then 
having it be in the environment is pointless -- and it means I must have 
an extraneous variable set that's only useful within a program that has a 
dot-rcfile.

> A while back, what I wanted was the ability to blank the screen after
> two minutes of inactivity, and then *lock* the screen after a further
> sixty seconds.  This would allow me to have auto-locking with a short
> timeout, without the annoyance of having to type my password if I look
> away -- because if I see the screen blank, I just tap a key to prevent
> it locking.

> Another problem I currently have with the built-in locker is that it
> prompts for my login password, even though I have a null login
> password.  So it doesn't matter what I type for the first password
> prompt, it always accepts it.

Whereas with a *'d password, it prompts twice the *first* time you lock, 
then uses that password for the remainder of the session.

Try this stuff, folks -- if nothing else, these unique cases should be 
mentioned in the documentation -- hell we've discovered one docbug just 
tonight.  Micah I apologize, I had discoverd this earlier, in noticing 
that there was no reference to /bin/lock in "strings screen" but neglected 
to mention it.

I think the password locking is one of the most useful features of screen, 
espeically for those of us who use it to "take our work home" and leave 
our workspace running, including root logins, doing slow builds or 
something like that.

But it's rather poorly done, really.

The disparity between the password needed to lock the screen, and to 
resume a session, for one.

Secondly, since I am able to lock the screen using my shell pass, I'm 
assuming there's some root privilege there -- which means in theory I 
should be able to use pam.

There's the simple *lack* of an external locking program that does half of 
these useful things.  tss would be great, if it could just read its 
password from some other file -- crypt is "good enough" for this case.

There's the inability in screen to specify multiple "idle" arguments 
(which would solve trent's argument, i.e. idle for 10 seconds, do this, 
idle for 30, do this).

In my case, there's the annoying lack of a kerberos-aware version of lock 
(which does have the ability to read login pass).

It really makes me want to learn C.

-Dan

--

"I love you forever eternally."

-Connaian Expression

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------