[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 20:21:38 -0500 (EST)
User-agent: Alpine 2.00 (BSF 1167 2008-08-23)

On Fri, 14 Nov 2008, Trent W. Buck wrote:

"Dan Mahoney, System Admin"
<address@hidden> writes:

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

In order to observe the output when I run "gpg -d" on an encrypted,
confidential file.  Simply having my login password would not grant
access to GPG encrypted files.

In order to observe the output of commands run on a remote host via
ssh.  Simply having my login password would not grant access to the
remote host.

If I leave ssh running inside the screen session, to actively modify the
remote host (e.g. installing your own public identity in the remote
authorized_keys file).

Right -- I had meant to answer those questions but the email was getting rather long-in-the tooth already. By answering them for me, you've proven that you "get it". :)

Similarly for other systems that require secondary passwords, such as a
remote IMAP server or a remote web application.

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

Clearly I don't know what you're talking about, because what I *thought*
you were talking about works as you ask for.

Namely, I run :password interactively to generate a hashed password in
the default register.  I use C-a ] to paste it into .screenrc, as in

   password ASDFASDFASDF

Yes, and it's used as a password on screen-reattach. Not when screen is locked.

I would like screen's built-in-lock to use that same password.

Later, in either the current or a new screen session, I run
:lockscreen.  It blanks the screen, changing it to

   Screen used by Trent W. Buck <twb>
   Screen password:

The first prompt is for my login password.  The second prompt is for my
screen password.

Exactly, it's asking for your login password. Probably gotten via a call to getpwnam.

Yes, and on my system, my passwd field in /etc/master.passwd is "*". If I do a ctrl-a-x, I get:

Screen used by Dan Mahoney <dmahoney>.

This is screen's builtin. Once I set that "key" there's no way to change it within that "attachment". Nor from what I can tell is there any way to set it without manually trying to lock your screen and getting whatever one gets on a failed password read.

To confirm, I'm not calling /bin/lock, which instead looks like this:

lock: /dev/ttyp6 on xxxxxxxxxx. timeout in 15 minutes.
time now is Fri Nov 14 00:55:22 UTC 2008

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

   echo password ASDFASDFASDF >~/.screenrc.secret
   echo source ~/.screerc.secret >>~/.screenrc

And which PAM module would that use?  Which facility, for that matter?

And Micah, we really at the point where you're thinking of linking against something as OS-specific as libpam (which varies widely from, say, Linux to BSD to Solaris)...when "just read the (or a different) password in .screenrc and use it for locking as well as on attachment" is a few lines of code that already exist?

the code already exists to generate a crypted password, and to compare it to the one in the file. The only thing you'd REALLY need is a knob that says "use the shell password, via getpwnam -- or "use the password in .screenrc" for locking. Re-attachment behavior would remain unchanged.

Given, there is a contention here -- two possibly separate passwords that you may have to enter twice. I might also suggest that there be some way (ala pam's try_first_password) to pass the same password you've used on "unlock" to the reattach function -- and if it doesn't work, have the reattach function re-prompt, instead of existing immediately.

Given, that requires more engineering (i.e. having screen prompt for an attach password multiple times) and such, the rest is simple.

-Dan Mahoney


"It's three o'clock in the morning.  It's too late for 'oops'.  After
Locate Updates, don't even go there."

-Paul Baecker
 January 3, 2k
 Indeed, sometime after 3AM

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