[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bigger annoyance with locking.

From: Dan Mahoney, System Admin
Subject: Re: Bigger annoyance with locking.
Date: Thu, 13 Nov 2008 04:34:39 -0500 (EST)
User-agent: Alpine 2.00 (BSF 1167 2008-08-23)

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.



"I love you forever eternally."

-Connaian Expression

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]