[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 22:08:50 -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 09:04:25PM -0500, Dan Mahoney, System Admin wrote:
It asks for *both* the login password and the screen session

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?

That sounds like Screen is not compatible with whatever Kerberos stuff
you're using.

As far as I know, the only real access to the system if via ssh, which does Kerberos all on its own, without pam, which makes it a "special case", just like with keyed ssh.

Which is why I've been pushing to have screen have it's "locking" (as opposed to attachment) password also be self-contained. It's trivial to do (at about the point I referenced, in fact).

Are you trying this with a "*"'d account, which is usable in
situations such as:

I have tested this on systems using null passwords, local md5
passwords, and NIS passwords.  I have not tested this on a system
using Kerberos for user accounts.

A "null" password is different from a "*"'d password, in my mind -- from a "login" point of view, one would not be prompted, the other would not be able to log in.

But you've stated that with pam in the mix and a "null" password, you basically get it accepting any password. So you too, are an audience for the "keep this password in .screenrc and be done with it" :)

NIS basically supplants your system's getpw* functions, so it should return an identical result as your standard ones.

#ifndef USE_PAM
[...]  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.

All my systems use PAM.

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.


I need to learn C.

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.

Probably Micah hasn't had to look at that part of the code yet.

Oh, there's #IFDEF and #IFNDEF all over the code. And I suspect part of the "resistance" here is because PAM is supposed to be such a universal answer, that we don't want to resort to local crypted passwords anymore.

Trivia: Disturbingly, screen's builtin locker was a kludge added in 1985!!!!



<Belldandy> ha. you have not met me.
<BaldDwarf> ha. but i have sene pictures
<Belldandy> thanks but uh.,
<BaldDwarf> seen dammit! SEEN!
<Gushi> I don't know who dammit! is.
<Belldandy> so anyway

-Undernet #reboot, October 2nd, 2000, 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]