This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] nsswitch: Add group merging support

On 04/13/2016 11:32 AM, Mike Frysinger wrote:
> On 13 Apr 2016 11:16, Carlos O'Donell wrote:
>> On 04/12/2016 01:53 PM, Mike Frysinger wrote:
>>>> You can _detect_ this behaviour by using an iterator to find these conflicting
>>>> entries and then play with /etc/nsswitch.conf to find the service which has
>>>> them and eventually remove them.
>>> what i previously requested was:
>>> 	could you clarify "undefined" ?  people could interpret this as memory
>>> 	corruption / crashes, while others are are inconsistent results.  i think
>>> 	we just want the latter.
>>> 	...
>>> 	in general i'm fine with "undefined", i would just prefer scoping it a
>>> 	bit.  it's "undefined" in terms of the result set, but it's not in terms
>>> 	of your program eating itself.
>>> so i don't think your desires are at odds with my request.  i simply want it
>>> to say that the return values (or whatever) are undefined rather than having
>>> the documentation imply all your programs will die an abort/assert crash, or
>>> enter the "undefined behavior" space like we have with "C undefined behavior".
>> I'm sorry, I missed that in your original response.
>> You raised a good point.
>> Let me rewrite it like this:
>> +When processing @samp{merge} for @samp{group} membership, the group GID
>> +and name must be identical for both entries.  If only one or the other is
>> +a match, the results are unspecified.
>> We use the C/C++/POSIX meaning of "unspecified behaviour" here.
>> That is to say that glibc imposes no requirements on what the results
>> should be if a misconfiguration is detected. However, the program is correct
>> and should not crash.
>> If you're OK with that then I'll use that wording.
> sgtm, thanks
> -mike
OK, so this is almost about ready to checkin.

The minor nit is that this patch creates new PLT entries in
and I need to determine if I can remove those with internal aliases
(since the nscd code should have recompiled copies and not need the


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]