Re: [PATCH] nsswitch: Add group merging support

[Mike Frysinger <vapier at gentoo dot org>]

On 12 Apr 2016 12:19, Carlos O'Donell wrote:
> On 04/04/2016 03:25 PM, Mike Frysinger wrote:
> >> +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.

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".
-mike

Attachment: signature.asc
Description: Digital signature