[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: Sun, 16 Nov 2008 14:55:54 -0500 (EST)
User-agent: Alpine 2.00 (BSF 1167 2008-08-23)

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