[Pkg-shadow-devel] redhat patches

Peter Vrabec pvrabec at redhat.com
Wed Nov 14 16:56:29 UTC 2007


Hi guys,

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

thnx. for comments. 
> 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."


>  * shadow-4.0.13-newgrpPwd.patch
>    I've committed the part which implement the following comment:
>    /* note: the original util-linux newgrp didn't ask for
>     * pasword if there is no password. It's better directly give up.
>     * -- kzak at redhat.com
>     */
>    I don't think the rest of the patch introduce any functionnal change.
>    Am I wrong?
>  * shadow-4.0.14-goodname.patch
>    RedHat specific (we have something similar for Debian).
>    I'm not sure about the chunk:
>    -    if (strlen (name) > sizeof (ut.ut_user))
>    +    if (strlen(name) + 1 > sizeof(ut.ut_user))
>    Not sure neither for the group name length.
>    I will keep it for latter.


>  * shadow-4.0.16-lOption.patch
>    This adds a new useradd option.
>    This will make the useradd implementation incompatible with other
>    implementation, but people are free not to use that option.
>    I think I will commit it.
fine, we use it to prevent useradd to add user to faillog/lastlog for example 
for user nfsnobody UID = -2

>  * 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.


>  * shadow-4.0.17-auditLogging.patch
>    Fixed by Tomasz => in 4.0.18.2
>  * shadow-4.0.17-exitValues.patch
>    Also fixed in 4.0.18.2
>  * shadow-4.0.17-login.defs
>    Config file => IMO, they have to be tuned by distributors
agree.

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

>  * shadow-4.0.17-redhat.patch
>    The oflg stuff is not needed (find_new_uid is always protected by
>    !oflg). Maybe an assert could be nice.
>    For the main part of the patch (new options), it seems to be
> controversial. My opinion is that they should be included, maybe with a
> note that software willing to be compatible with other implementation shall
> not use these options.
>  * shadow-4.0.17-useradd.patch
>    I would prefer to have some kind of script or a set of script in a
>    directory for this.
>    To be checked later.
>  * shadow-4.0.18.1-appendOption.patch
>    Fixed in 4.0.18.2
>  * shadow-4.0.18.1-gid.patch
>    Fixed in 4.0.18.2 + 4.0.19
>  * shadow-4.0.18.1-overflow.patch
>    Committed. (maybe with some indentation changes).
>  * shadow-4.0.18.1-sysAccount.patch
>    I don't remember;)
forget it for now. It change order in which we add sys accounts.
we start at 500 and than go down to 100 looking  for free slot.

>    Probably has to be checked again after inclusion of
>    shadow-4.0.17-redhat.patch
>  * shadow-4.0.18.1-useradd
>    Config file
>  * shadow-4.0.3-noinst.patch
>    Distribution specific (but I'm not sure there is a distribution which
>    choose to distribute the shadow library).
I think you can commit it.

>
> Kind Regards,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: shadow-4.0.18.1-sha256.patch
Type: text/x-diff
Size: 6753 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20071114/e936385e/attachment.patch 


More information about the Pkg-shadow-devel mailing list