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

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

On Thu, Nov 13, 2008 at 08:21:38PM -0500, Dan Mahoney, System Admin wrote:
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.

My experimental evidence directly contradicts your assertion.

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

Exactly, it's asking for your login password.

It asks for *both* the login password and the screen session password.

Yes, and the point is: I don't have a login password, so upon "locking" I am given the opportunity to create one, which has no persistent form of storage? Are you trying this with a "*"'d account, which is usable in situations such as:

* In the presence of SSH host-keys.
* Under Kerberos
* In systems where "role" accounts are limited to sudo-only. For example, my "mailman" account is like this, since I occasionally need to su to it to run cleanups.

Whereas you have asserted that your password is "blank", mine's "*", which I guess should both yield different behaviors.

It all happens somewhere around line 816 of attacher.c -- where there's a call that basically says :

#ifndef USE_PAM
  pass = ppp->pw_passwd;
  if (pass == 0 || *pass == 0)

You can see the code that I'm talking about that prompts for a key shortly after.

I have no idea about that call or its returns, but on the system I'm on, this is what's happening. I should note that that block is only in use if you're *not* using pam, which I guess is how the BSD port builds things.

If you're not seeing the above behavior, you probably have screen compiled with PAM support -- which from your pov likely means your "unlock" password's being passed through that stack.

From a quick lookover of the BSD port, there's no option to enable (or
disable) pam, nor does the port do so by default -- I don't know what system you're on, but this is likely where we find the difference between what I see and what you see.

Up till a few minutes ago, I wasn't aware screen even supported pam at all, after all no mention is made of it in the manpage, I find nothing if I grep -i any of the README/INSTALL/TODO files in the release. A grep -i pam in the doc subdir yields zero hits.

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

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

It doesn't use PAM, because it's not a system-wide password.  It's a
separate per-session password specific to Screen.

If you want to confirm my crazy, send me an ssh pub key and I'll give you a shell on my system (obviously, I can't just give you a password).

Screen prompts for the login password before the session password, and
the former COULD be gotten via PAM.

If the pam support had been tested at all on this distro -- even from what Micah said previously: "I would support extending screen's builtin lock to support PAM" -- led me to believe screen was pam-unaware until I just now looked at the code.



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