* [2008-05-22 18:59:48 +0000] Dick Gevers wrote:

>>>>- PASS_MIN_LEN seems no longer valid for some reason, so comment it out
>>>>to get rid of warning messages when creating new users
>>>
>>>Sorry, but after this version that problem remains.
>>
>>Did your login.defs get replaced, or do you have a .rpmnew file?
>
>Yup, but taken care of.

Hmmmm...

That should be sufficient. Where are you getting the warning about
PASS_MIN_LEN being invalid still?

[root@(protected)
#  PASS_MIN_LEN  Minimum acceptable password length.
#PASS_MIN_LEN  5
[root@(protected)
[root@(protected)
uid=1012(foo) gid=1012(foo) groups=1012(foo)

I'm not seeing it here.

>>>Another is that with userdrake I don't seem to be able to change a user's
>>>password (after having converted to tcb): /etc/tcb/user/shadow is not
>>>changed, but after I try with userdrake, that user can neither use his old
>>>nor his new password.
>>>
>>>Please let me kow if I should post it to bugzilla.
>>
>>Please open a bug report. I'm actually on holidays this week, so I'm
>>not sure when I'm going to get a chance to look at it.
>
>https://qa.mandriva.com/show_bug.cgi?id=40998

Thanks.

>>What you can try is finding the userdrake binary and making it sgid
>>shadow (i.e. chown root:shadow userdrake && chmod g+s userdrake). That
>>might be all it needs.
>
>That's not the problem: I was working as root for that (thowaway) user
>maintenance.

Yeah, but it being executed by root may not be enough. There are
additional checks going on here to tighten security, so it may need to
be group shadow or group chkpwd.

>>But if you do file a bug report, please provide some more info as I'm
>>not sure what you mean. When you try to change a user's password with
>>userdrake, the shadow file isn't touched, but afterwards you can't login
>>with the old or new password at all?
>>
>>If that's the case, then the file must be changed or userdrake has
>>changed something else.
>
>See # 40998
>
>But a second ago I see the new pam in changelog with
>> - dropped the system-auth migration as per blino
>
>which I hope does not mean all work was wasted.

No, pam_tcb is still default. Before there were a few instances where
it would fail to authenticate because pam_unix assumes 'shadow' across
the board, but pam_tcb does not. Now that that is fixed, anything
calling pam_unix (which is a symlink to pam_tcb) should work.

Of course, this means that anyone who wants blowfish passwords or wants
to use tcb will have to manually change their system-auth file. I'm not
quite sure why this is better, but I don't want to fight about it. I
think it did the right thing, and did it properly, but others disagree.

Personally, I think it's silly, but whatever. pam_tcb is still the
default and once I can demonstrate to all the poo-pooers that using tcb
instead of /etc/shadow is seamless, then maybe we'll get full tcb
support by default (which, I might add, Openwall and ALT have had for
over 6 years and Annvix has had for 2 years).

--
Vincent Danen @ http://linsec.ca/