[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:41:02 -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 10:08:50PM -0500, Dan Mahoney, System Admin wrote:
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" :)

Nope.  The session pasword is already in .screenrc, and it should stay
there.  But the login password should NOT need to be specified to
Screen in any way but PAM.  That's what PAM's there for, and I'm happy
with it.

I imagine that I am prompted for a null login password because Screen
is not using PAM quite correctly.

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

To clarify: I meant NIS *via PAM*.

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.

Do you dispute this?  Can you provide a concise explanation of why PAM
is not sufficient?

Concise: Because not all systems have PAM, and some of those lack standard getpw* interface to get the encrypted password. Heck, in some there IS no password.

Detailed: Kerberos and ssh-keys are two such examples. I am sure there's at least one or two others, obscure though they may be.

I'm not saying using pam where it's available isn't a great answer. I'm in favor of it -- but screen's pam support isn't well-publicized, and I don't know how widely tested it is. I'm not about to enable something my ports maintainer doesn't seem to be aware of, in the authentication portion of setuid program designed to be used by non-root users.

Either way, it's *not* everywhere, and the simple ability to use this other password "if all else fails". (I.e. in the same situations under which I'd be prompted with the "Key" prompt above) -- are an edge case, but they've reared themselves.

Prompting for a password (to use, not to try) on a manual lock is smart...having no way of keeping such a password persistent across foreground screen sessions or changing that password once set, or no way having your "first lock" be time-based (as it'll just sit there, saying "key: ", which you can ctrl-c)...are all I think bugs. Rarely encountered, but bugs none the less.



<Zaren> Christ almighty...  my EYES!  They're melting!

-Zaren, Efnet #macintosh, in response to:
The WEBSITE DESIGN class that gave my fiancee a 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]