Re: Bigger annoyance with locking.

[Micah Cowan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Mahoney, System Admin wrote:
> 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?

Because the locking is handled by the attaching screen, not the backend
screen.

> 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.

There are tons of instances of application-specific environment
variables. SSH_ASKPASS and the like. It's useful anywhere you want to
set a global setting for anything run by a particular shell and its
descendants. Yes, the dot-rcfile does that too, but the dot-rcfile is
stored in the screen backend, whereas this setting is used by the frontend.

> 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.

It isn't intended to be particularly powerful. Locking the terminal
isn't screen's "job", that's why I'd prefer to extend the external lock
program, rather than give screen an ultra-cool one (that only it can use).

> 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.

I would support extending screen's builtin lock to support PAM. Another
extension I'd support is MD5-hashed passwords, on those systems that
support it. 8-char-limited passwords is a PITA.

> There's the simple *lack* of an external locking program that does half
> of these useful things.

Well, exactly. Isn't it better to address that situation, rather than
throw all the stuff you want into screen?

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkcaZkACgkQ7M8hyUobTrERYACfftto0hr+3poZa70E64QfvdF2
Ol4An09H5ttcNZGZKK53z4afrazLF4i9
=gYI2
-----END PGP SIGNATURE-----