[Pkg-shadow-devel] redhat patches

[Nicolas François]

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.

Just some questions regarding the shadow patch:
 1 Does PAM supports these password schemes (for password creation and
   authentication)?
   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.
 3 Are all the buffers which contain encrypted passwords long enough?
 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.
 6 chpasswd and chgpasswd will need some new options.

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?

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.

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.

> >  * 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,
-- 
Nekral