[Pkg-shadow-devel] redhat patches

[Peter Vrabec]

On Thursday 15 November 2007 01:15:58 am Nicolas François wrote:
> Hi,
>
> Just a quick answer. I will try to have a deeper look this week-end.
>
> On Wed, Nov 14, 2007 at 05:56:29PM +0100, Peter Vrabec wrote:
> > these is one important patch that we need to push to upstream. It enable
> > shadow-utils to use new glibc code for different password hashes. It
> > would be nice start using it as soon as possible.
> >
> > Take a look at:
> > http://people.redhat.com/drepper/sha-crypt.html
>
> I knew there were some plans, I did not imagine they were so concrete!
>
> I had a look at Ulrich paper and specification. Not much comments. Sounds
> good.
>  * blowfish could be nice for people not only interested by the NIST
>   argument. But this is glibc stuff.
>  * "The maximum salt string length is raised to 16. Not really because 8
>    bytes [...] is not enough. More because varying sizes of the salt
>    string adds additional entropy when the attacker does not know the salt
>    string." (http://people.redhat.com/drepper/sha-crypt.html)
>      I don't think that is true. IMO, the varying size adds less than one
>      bit of entropy. So moving from 8 to 16 adds much more entropy.
>      I don't think that is important though, I don't think having a fixed
>      size entropy is interesting neither and having a minimum of 8 bytes
>      is quite good.
good for me, too :-)

> Just some questions regarding the shadow patch:
>  1 Does PAM supports these password schemes (for password creation and
>    authentication)?
in next upstream release.

>    I guess there is not much to do since everything is done in crypt().
>    But the pam_unix module may need a sha256/sha512 option (and maybe a
>    count option).
>  2 How does your patch behaves with an old libc?
>    The configure script will need an option and maybe a detection script.
you are right, we need to check glibc in configure.

>  3 Are all the buffers which contain encrypted passwords long enough?
They supposed to be alright.

>  4 Is there a need for a count option, set by the admin depending on the
>    server CPU resources and needed password strength.
>  5 Is the algorithm stable enough to avoid the rounds= parameter?
>    (i.e. the default # of rounds is currently 5000. If it is not
>    specified in the password, and if the libc changes the default number
>    of rounds used by crypt, that would mean a lock of users accounts)
>    It could be safer to always specify the number of counts.
I'll ask Ulrich about this. But I hope it's not needed to use  rounds= 
parameter.

>  6 chpasswd and chgpasswd will need some new options.
true.

> I don't think any of these should delay the inclusion of the patch (but
> 2, 3, and 5 should be clarified before the 4.0.19 release).
>
> Thanks for the patch.
>
> > > Here are some comments on the RedHat patches (based on
> > > shadow-utils-4.0.18.1-13.fc7.src.rpm):
> > >  * shadow-4.0.11.1-vipw.patch
> > >    Is it still needed?
> > >    What are /etc/ptmp and /tmp/gtmp?
> > >    Are they standard lock files used by other common/recent software?
> >
> > I found that it  fix #6489
> >
> > "It is possibile to add an user with useradd while someone
> > else is editing the passwd file with vipw. vipw does acquire
> > some lock, preventing multiple istances of itself from
> > running at the same time, but useradd probably uses a
> > different locking scheme. I understand the two executable
> > belongs to different packages (shadow-utils-19990827-2 and
> > util-linux-2.9w-24) but i think they should interact
> > correctly."
>
> I will check more recent version of util-linux.
>
> On Red Hat systems, does vipw/vigr (still) come from util-linux?
>
> Wouldn't it be better to check the presence of these util-linux lock files
> in pw_lock & gr_lock?
I talked to util-linux upstream/maintainer (one person). We will stop using 
vipw from util-linux and start using one in shadow-utils.  Therefore this 
patch isn't important anymore.

> Are there other lock files for the shadowed databases (/etc/shadow &
> gshadow)?
>
> > >  * shadow-4.0.16-nscd.c
> > >    Why is the current nscd_flush_cache implementation not sufficient?
> >
> > That was a long story :-)
> > https://bugzilla.redhat.com/show_bug.cgi?id=191464
> > comment #
> > Ulrich Drepper:
> > "Nobody is allowed to use that socket outside of glibc.  The
> > protocol is private.  That's the whole reason for the problem."
> >
> > I'll appreciate if you commit it.
>
> OK. I will just check if there are no new glibc function to flush the nscd
> tables since 2006-06-04.
thnx.

>
> I need also to see whether the patch works when nscd is not present (at
> least it is the case on Debian by default).
> I would prefer this case to be handled with no warnings/errors.
ok

> > >  * shadow-4.0.17-notInheritFd.patch
> > >    Only useful when shadow-4.0.16-nscd.c is used?
> > >    Upstream implementation does not execve, but uses a socket.
> >
> > right
>
> Will be committed with shadow-4.0.16-nscd.c
>
>
>
> PS: Mike, I'm also committing gentoo patches;)
>
> Best Regards,