Re: Bigger annoyance with locking.

[Dan Mahoney, System Admin]

On Fri, 14 Nov 2008, Andrew Deason wrote:

> On Thu, 13 Nov 2008 22:41:02 -0500 (EST)
> "Dan Mahoney, System Admin"
> <address@hidden> wrote:
>
> > On Fri, 14 Nov 2008, Trent W. Buck wrote:
> >
> > > 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.
>
> Erm, this is confusing. Are you providing Kerberos as an example where
> PAM is not sufficient? Because PAM works very well with Kerberos.

On BSD, from ports, on the system I am on -- there is no pam.  There's not 
an option to build screen with pam at all, unless you do so manually. 
This is how all BSD systems build screen from ports, since forever.  On 
this system -- SSHD uses kerberos natively.  It has this ability going 
back as far as I can tell, predating PAM's existence in BSD (and possibly 
pam's existence in linux but I'd have to check the history books on that).

Even WITH pam -- how does this translate in the case of ssh-key login 
where there is no password?

That said, my options are:

1) Re-engineer everything we're doing to support pam, ONLY for screen. 
AND start using a screen (as stated, a program designed to run as root and 
be run as normal users) under options that according to the maintainer 
"should work" but that have never been tested (and note -- there's been 
numerous cases of disparity before between linux pam behavior and BSD). 
On top of which, I'm not sure even Micah is sure how well the pam support 
actually works, since earlier in this thread he said he'd support 
extending this.  Even after that, I'd had to argue with management to get 
this implemented, since it's a system-level change rather than a simple 
feature tweak in screen.

2) Ask the screen developers for one more "if statement" that says:

If pam's not defined, AND "if you can't get my shell password somehow" 
(and this much is already in the code)...

AND if I have a password set in my .screenrc, lock the screen with that.

Otherwise, prompt for a key.  (this is already in screen, but nobody on a 
pam system will ever see it -- people on PAM systems with */null 
passwords will likely just get a password prompt that accepts any password 
and lets you back in.)  This suggests that the PAM support was at the 
least, badly done.

That's all.  You tell me which is simpler, here.

Yes, I'll have to put in the same password twice, once to unlock the 
screen and once to attach it.  Right now my "lock" is a prompt that says 
"Key:" that I can ctrl-c.

As I've already stated, I know we're catering to an edge case here. 
However, a good portion of that edge case is already accounted for in 
every shipping version of screen.  I feel as though by asserting that this 
is an actual case, that people feel I'm crazy.  I know at this point I've 
touched on several crossing issues and I know I feel as though I'm 
repeating myself.  I'm sure you all are getting tired of it too.

Yes, this is a real issue.  No, linux users won't see it.

As I offered to Trent and Micah -- if you want a shell on my BSD systems 
(it will have to be ssh-key-only to catch this), feel free to send me a 
key (or an email under separate cover -- you can set up your own key and 
I'll null your pass after you're done) and I'll let you log in.  I'm 
willing to contribute my box as a dev system here in order to get this 
fixed.

> Unless you mean you're trying to authenticate with already-existing
> Kerberos tickets without supplying a password, but that seems silly.

Screen's not kerberos aware without PAM.  I don't have pam.

-Dan

--

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------