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.
-Dan
--
<Zaren> Christ almighty... my EYES! They're melting!
-Zaren, Efnet #macintosh, in response to:
www.geocities.com/CollegePark/Classroom/1944
The WEBSITE DESIGN class that gave my fiancee a D.
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
