Re: Bigger annoyance with locking.

[Dan Mahoney, System Admin]

On Thu, 13 Nov 2008, Micah Cowan wrote:

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

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

http://www.nabble.com/Locking-screen-td290704.html

-Dan

--

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

-Chris D.

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