On Mon, Aug 8, 2022 at 1:41 PM Frank Ch. Eigler <f...@redhat.com> wrote:
> So-so ... if the file contents are modified, but the environment
> variable that points to the file is fixed, then one may get into parse
> race conditions as different debuginfod client objects in the process
> may be active at the same time.
>
Ah, that's a good point. To support dynamic updates you'd need to
completely reload config for each query, which is prohibitive, and you may
get inconsistencies in behavior. So that just leaves file permissioning as
a use case.
>
> > [...] You could also do this more granularly:
> > DEBUGINFOD_HEADERS_FILES would work for us, and other lists could be
> > created for other dynamically controllable aspects of the system.
> > [...]
>
> I see some value in doing this sort of thing more broadly,
> hypothetically, but it's vague/speculative enough that I'd be just as
> glad to limit the concept to the present case ("also add all headers
> in given file"). So how about a $DEBUGINFOD_HEADERS and perhaps
> $DEBUGINFOD_HEADERS_FILE env vars for now?
>
Sounds good to me. If permissions are the only benefit to ..._FILE
environment variables, then headers are the only bit of config that it
makes sense to access control, so it makes sense as a special case.
--
Daniel Thornburgh | dth...@google.com
