Bug 18889 - pam does not accept HPUX passwords shared over nis
Summary: pam does not accept HPUX passwords shared over nis
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam (Show other bugs)
(Show other bugs)
Version: 7.0
Hardware: i386 Linux
high
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 18104
TreeView+ depends on / blocked
 
Reported: 2000-10-11 14:16 UTC by Jorit Dorn
Modified: 2007-03-27 03:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-15 02:25:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jorit Dorn 2000-10-11 14:16:02 UTC
The Red Hat Linux 7.0 pam authentification does not accept HPUX passwords
shared 
over nis. HPUX adds the aging information behind the password.

Example: after the comma is the aging information (A/3N)
...> ypcat passwd | grep dornjt
dornjt:eXjc5l6c/iOD6,A/3N:19713:20102:Jorit Dorn:/home/dornjt:/bin/tcsh
(BTW this is not my real password ;-)

Copying the old configuration from Red Hat 6.2 fixes the problem.

Without a standard fix or the information that using the old config files
is secure,
we cannot upgrade to Red Hat 7.0 which we at our university (a pool with 70
PCs) 
for our Computer Graphics Department (we need the OpenGL support for NVIDIA
cards.

Greetings
 Jorit

Comment 1 Alan Cox 2000-10-14 22:26:37 UTC
I would say that 7.0 is correct in rejecting the broken HP NIS entries. I'm not
aware of any reason that using the older PAM module should have any security
implications. Obviously you need to watch for future 6.2 errata to the PAM
modules if you do this.

Im leaving this bug open, its not clear that 'HP/UX is wrong' is sufficient of
an answer and we probably should look at teaching PAM about this paticular HP
quirk.


Comment 2 Jorit Dorn 2000-10-15 12:49:45 UTC
> I would say that 7.0 is correct in rejecting the broken HP NIS entries.

I'm sorry, but your definitly wrong. The HPUX passwords is a documented feature
of nis on a HPUX machine. This is _not_ a bug on the HPUX side. 

It used to work with Red Hat Linux 6.2. You changed the behavior on RH 7. So
please do me a favor and fix it instead of arguing that HPUX is broken.

Thanx Jorit




Comment 3 Nalin Dahyabhai 2000-10-26 21:37:52 UTC
Please check if the pam-0.72-32 packages in http://people.redhat.com/nalin/test/
fix this problem for you.  A workaround has been added to the pam_unix module to
ignore the aging information.

Comment 4 Jorit Dorn 2000-11-08 12:18:15 UTC
Hi, I've been hauting some other bugs on our running system so I wasn't able to
test, sorry it took so long.

Yes it seems to work fine but in my opinion the aging information should not be
ignored. A collegue figured out the encoding for the HPUX aging information I
going top post it this afternoon (hopefully).

Greetings
Jorit


Comment 5 Jorit Dorn 2000-11-08 18:41:14 UTC
Hi again ;-)
I got the aging information encoding. It's four byte
1st byte: vality duration (in weeks)
2nd byte: minimum time untill a change is allowed (also in weeks)
3rd an 4th byte: date last changed (in weeks since the 1.1.1970)

The encoding for the numbers is:
. => 0
/ => 1
0 => 2
...
9 => 11
A => 12
...
Z => 37
a => 38
...
z => 63

The last change date is (in [] is the byte):
[3]+[4]*64

That makes something like 4095 weeks or approx. 78 years so there will be a
y2048 problem in HPUX :-)

It would be a good extension to the pam modules to recognize the expiration date
on the linux clients :-)

Greetings
 Jorit



Comment 6 Nalin Dahyabhai 2001-02-12 20:28:35 UTC
The problem with this method of encoding the information is that pam_unix
expects aging information to be returned when it calls getspnam(), which I doubt
is smart enough to parse this out of the user's password field.

Comment 7 Jorit Dorn 2001-02-12 20:39:46 UTC
- who's responsible for the pam modules? (who to send a patch when availible -
might take some time)

since this did not work before with the red hat 6.2 it isn't this important :-)

Jorit

Comment 8 Mike A. Harris 2001-12-01 14:17:29 UTC
You can attach a patch directly to the bug report if you like.

If you feel this problem is fixed now however, or no longer relevant
to you, feel free to close the report.


Note You need to log in before you can comment on or make changes to this bug.