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/04/2016 03:25 PM, Mike Frysinger wrote:


Thanks for the review. Sorry for the frustration.

[snip formatting objections]

I'll fix the formatting before checking it in myself on behalf of Stephen.

I see only two places that needed cleanup:

Fixed BUFCHECK in grp/grp-merge.c
Fixed CHECK_MERGE in nss/getXXbyYY_r.c
Comment nit in grp/grp-merg.c s/NSS_STATUS NOTFOUND/NSS_STATUS_NOTFOUND/g

>> +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 behavior is undefined.
> as i asked previously, why can't we scope the undefined part a bit ?

Thanks for raising this issue again.

Lets hash it out.

It is undefined behaviour because that was easiest and gives the biggest
implementation-dependent flexibility.

If you have configured a system where a user has two different GIDs across
two merged services (same database) for a given group name, then you have
a misconfigured system. Depending on the availability of the services a
group name might change GID. This can cause serious problems. You might
get one GID one day, a different GID the other day. This can happen
*today* without the use of MERGE if you have two services and one becomes
temporarily inaccessible _and_ the services have conflicting numeric GID
for the same group name.

With the use of MERGE the problem is still the same, but now it impacts
the semantics of the merge operation (which always happens).

The proposed implementation ignores the second service that returns
a result with a non-matching GID or non-matching group name. Even though
the service returns a result it is treated as NSS_STATUS_NOTFOUND, and the
results are ignored as inconsistent with the results of the first service
that returned a result.

This results in a conservative set of results being returned. If the first
service is temporarily unavailable, the user will see their group GID change,
similar to the problem we have today with unavailable.

It seems wrong to return an error condition if the inconsistency is detected,
since this is not very "fail safe", and could leave you unable to use the
system at all.

We don't have enough usage data to say if this choice is what we need, and
so the suggestion to say "undefined behaviour." I hope that what is proposed
becomes acceptable over time, and it can eventually be documented.

Until then I'd like to see this remain undefined behaviour.

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.



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