[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.
-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
---------------------------
- Bigger annoyance with locking., Dan Mahoney, System Admin, 2008/11/13
- Re: Bigger annoyance with locking., Micah Cowan, 2008/11/13
- Re: Bigger annoyance with locking., Trent W. Buck, 2008/11/13
- Re: Bigger annoyance with locking.,
Dan Mahoney, System Admin <=
- Re: Bigger annoyance with locking., Micah Cowan, 2008/11/13
- Re: Bigger annoyance with locking., Dan Mahoney, System Admin, 2008/11/13
- Re: Bigger annoyance with locking., Trent W. Buck, 2008/11/13
- Re: Bigger annoyance with locking., Dan Mahoney, System Admin, 2008/11/13
- Re: Bigger annoyance with locking., Trent W. Buck, 2008/11/13
- Re: Bigger annoyance with locking., Dan Mahoney, System Admin, 2008/11/13
- Re: Bigger annoyance with locking., Trent W. Buck, 2008/11/13
- Re: Bigger annoyance with locking., Dan Mahoney, System Admin, 2008/11/13
- Re: Bigger annoyance with locking., Trent W. Buck, 2008/11/13
- Re: Bigger annoyance with locking., Dan Mahoney, System Admin, 2008/11/13