[Pkg-shadow-devel] redhat patches
Nicolas François
nicolas.francois at centraliens.net
Thu Nov 15 00:15:58 UTC 2007
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
More information about the Pkg-shadow-devel
mailing list