[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pwdb breakage



On Fri, 30 May 1997, Michael K. Johnson wrote:

Hi all,

The issues involved in this message seem to be very seriuos, I am
dedicating this weekend to the issue. Anyone on-line ableo to provide me
with feedback please stay tuned, I'd like to solve those problem as
quickly as I can, otherwise I'll need to postpone an exam I have on
monday, and ... I'll do it if I have to. :-(

So, point by point...

> First, try this:  for some user, put a password field of
>  x in /etc/passwd
>  * in /etc/shadow
> This means that (x) shadow should hold the password, and (*) that
> the password is locked.  Now use passwd <user> to set that user's
> password.  The password will be put in /etc/passwd instead of
> /etc/shadow. (If you use the "shadow" argument to /etc/passwd,
> it does put the entry in /etc/shadow, but it does so unconditionally,
> which is also not standard shadow password behavior.)

This is the _expected_ behavior of the pam_pwdb module ! It will _read_
the shadow passwords, it will honor them; *but* if you don't have the
'shadow' arg to the pam_pwdb module, it will understand that you are
dealing with a graduate unshadowing process on your system, so it will
convert the shadow passwords to standard ones as each user changes
his password (or root is setting that). I thought that the docs were
pretty clear on this one, I fail to see the problem. What is the problem ?
Anyone have other ideas ?

> In general, it appears that if /etc/shadow contains a * password,
> the password is modified in /etc/passwd instead.

No, the only difference is made by the presence/absence of the 'shadow'
arg to pam_pwdb.

> If /etc/passwd contains a * (not x) password, that means that the
> account should be locked, and /etc/shadow should not be consulted
> for that user.  Instead, it is ignored, and /etc/shadow is consulted.

Now, this is a bug. Thanks. I'll try to address this asap.

> Andrew, I know that there was one problem that you found that I couldn't
> reproduce; was it related to any of these?

The problem was: if the 'shadow' arg is given to pam_pwdb and no
/etc/shadow exists, the /etc/passwd is updated in a shadow manner ('x' as
a passwd), but /etc/shadow is not created. In the latest pam_pwdb from
0.58-preC this is addressed.

> There are also endianness dependencies in pwdb that Erik is looking into.

I've seen those. I have the patch, howeverm there are few more places one
will have to look into (that one is me at the moment). Thanks for pointing
out, I am re-reading the code at least for the uid/gid part, which impose
a security threat. Patching is under way.

Anyone having comments, please speak now...

Best wishes,
		Cristian Gafton
--
--------------------------------------------------------------------
Cristian Gafton                                    gafton@sorosis.ro
Computers & Communications Center              Network Administrator
http://www.sorosis.ro/~gafton                          Iasi, Romania
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is user friendly. It's just selective about who its friends are.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []