[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 15:09:18 -0500 (EST)
User-agent: Alpine 2.00 (BSF 1167 2008-08-23)

On Thu, 13 Nov 2008, Micah Cowan wrote:

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

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

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.

And you're saying the frontend doesn't read that file?

SSH_ASKPASS is an interesting example, for a few reasons:

1) SSH also supports a builtin method to do so.

2) SSH_ASKPASS is used to display a (possibly graphical) password-asking app, and thus is dependent on your outlying environment. I.e. if you're running X, it's one thing, gnome, it's another, kde, maybe another...i.e. it's used in multi-modal situations in which you might run the ssh command.

Does the tool used to lock a screen (either a pty or an xterm) change in this manner? Is the locking of an xterm-screen any different from a pty-screen. Set it dark, accept no input, accept no termination characters.

(I assume not, but perchance older hardware terminals may be different -- If there's that much variance, isn't this better expressed as some variable in termcap? (or some screen code which takes such variables into account.)

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

And yet screen's internal lock does a *better* job than anything else I've found -- for example, a locked screen with a builtin tool, I really cannot get past without killing screen. A locked screen with an external, all I have to do is kill the program -- of course, then I'm at the mercy of being able to attach my detached screens (which requires a password in all "sane" cases).

Hypothetically, if I've cracked my screen password (which is available to my uid for easy cracking) but NOT my login password (which is only accessable by root) -- breaking an internally locked screen is harder.

The question comes up: "if I can get at your uid, why do I need your screen?"

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.

Sadly, even though I am root on the systems involved -- the tweak we really need here is extending screen's builtin lock to support the password stored in .screenrc -- otherwise it's a whole new pam facility -- and PS, incidentally, pam doesn't have an easy way to say "use the password in this file." I mean, yes, I absolutely could use the pam_kerberos libraries there, but it doesn't solve things for the larger audience.

Another extension I'd support is MD5-hashed passwords, on those systems that support it. 8-char-limited passwords is a PITA.

Actually, that's a simple extension of the "salt" used in the crypt() function of the underlying OS -- possibly a very small change, but remember that it does make your .screenrc less portable.

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?

Why not bundle such a thing as a contrib?

I've found a couple -- they don't do what's needed. Some support very nice ascii art screensavers (which is very cool) but both I've found require root for various reasons, and I think this is less-than-desirable.

I may, depending on the final output of our conversations here, contact them and ask them for the following:

I'm not against a program which can read its argument as either a) piped to stdin (encrypted or not), b) read from a file (encrypted of course), or c) supplied as a command line argument (encrypted).

Of course, in cases A and C above, screen would need to be modified slightly to gain the ability to send that password. In case B, it's another password to maintain.

And yes, this means that option would probably have to become a .screenrc tunable.

I should note that I've been over some of this before, but with more of a focus on non-attachment. (i.e. if you get past password #1, but not password #2, you still get a shell -- whereas I'd like to just "relock")



"Goodbye my peoples.  I'll miss each one of you.  Sniff-Sniff I now know
the true meaning of love.  Thank you Sniff-Sniff.  You are all in my

-Chris D.

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