Re: Bigger annoyance with locking.

[Dan Mahoney, System Admin]

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