https://sourceware.org/bugzilla/show_bug.cgi?id=32318
--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
While thinking through implications of this change and the preexisting
configuration possibilities, I happened across this unfortunate finding,
added to doc/debuginfod-client-config.7
It is possible for IMA configurations to be ambiguous, for example if
a requested object is queried through a \fBDEBUGINFOD_URLS\fP
specification that includes \fImultiple\fP servers with
\fIdifferent\fP \fIima:\fP policy modes. Consider if the object is
available from each of those servers, but with an absent or invalid
signature. The client may query all servers concurrently. If the
client happens to receive the object from an \fIima:enforcing\fP
policy server first, the query will rejected, but if it's from an
\fIima:ignore\fP policy server, the query will succeed.
Let's assume this isn't easily avoidable. If so, then the possible
implementation patch attachment is pointless, because its results
in the subject case will be flatly in the ambiguous category.
(The code above happens to squash it into ima:ignore, but that's an
implementation artifact accident.)
It is definitely NOT equivalent to the "ima:permissive" mode we
have repeatedly discussed and noted in bug #31842. (The multiple-modes
ambiguity would remain EVEN IF we had a first class ima:permissive mode.)
(Why is this not easily avoidable? One reason relates to the
way we use libcurl. We deliberately launch multiple outgoing queries to
named servers concurrently. As soon as any one starts feeding us data,
we abort the queries to all the others, to avoid downloading something
potentially large multiple times. It's non-deterministic.)
--
You are receiving this mail because:
You are on the CC list for the bug.
