[PATCH] debuginfod-client: Add DEBUGINFOD_HEADERS_FILE.

[Daniel Thornburgh via Elfutils-devel]

This DEBUGINFOD_HEADERS_FILE environment variable names a file to supply
HTTP headers to outgoing requests. Notably, this allows for
Authorization headers to be added from a file under OS access control.

Signed-off-by: Daniel Thornburgh 
---
 NEWS|  3 +++
 debuginfod/ChangeLog|  5 
 debuginfod/debuginfod-client.c  | 44 +
 debuginfod/debuginfod.h.in  |  1 +
 doc/ChangeLog   |  4 +++
 doc/debuginfod-client-config.7  |  7 ++
 doc/debuginfod_find_debuginfo.3 | 12 ++---
 7 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index 6ebd172c..3df652e3 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,9 @@ Version 0.188 some time after 0.187
 
 readelf: Add -D, --use-dynamic option.
 
+debuginfod-client: Add $DEBUGINFOD_HEADERS_FILE setting to supply outgoing
+   HTTP headers.
+
 debuginfod: Add --disable-source-scan option.
 
 libdwfl: Add new function dwfl_get_debuginfod_client.
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index 59d50df1..1df903fe 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2022-10-18  Daniel Thornburgh 
+
+  * debuginfod-client.c (debuginfod_query_server): Add DEBUGINFOD_HEADERS_FILE
+  setting to supply outgoing HTTP headers.
+
 2022-10-17  Frank Ch. Eigler  
 
* debuginfod.cxx (main): Report libmicrohttpd version.
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 2a14d9d9..549520c1 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -42,6 +42,7 @@
 #include "config.h"
 #include "debuginfod.h"
 #include "system.h"
+#include 
 #include 
 #include 
 
@@ -447,6 +448,44 @@ add_default_headers(debuginfod_client *client)
   free (utspart);
 }
 
+/* Add HTTP headers found in the given file, one per line. Blank lines or 
invalid
+ * headers are ignored.
+ */
+static void
+add_headers_from_file(debuginfod_client *client, const char* filename)
+{
+  int vds = client->verbose_fd;
+  FILE *f = fopen (filename, "r");
+  if (f == NULL)
+{
+  dprintf(vds, "header file %s: %s\n", filename, strerror(errno));
+  return;
+}
+
+  while (1)
+{
+  char buf[8192];
+  char *s = &buf[0];
+  if (feof(f))
+break;
+  if (fgets (s, sizeof(buf), f) == NULL)
+break;
+  for (char *c = s; *c != '\0'; ++c)
+if (!isspace(*c))
+  goto nonempty;
+  continue;
+nonempty:
+  ;
+  size_t last = strlen(s)-1;
+  if (s[last] == '\n')
+s[last] = '\0';
+  int rc = debuginfod_add_http_header(client, s);
+  if (rc < 0)
+dprintf(vds, "skipping bad header: %s\n", strerror(-rc));
+}
+  fclose (f);
+}
+
 
 #define xalloc_str(p, fmt, args...)\
   do   \
@@ -610,6 +649,11 @@ debuginfod_query_server (debuginfod_client *c,
   if (maxtime && vfd >= 0)
 dprintf(vfd, "using max time %lds\n", maxtime);
 
+  const char *headers_file_envvar;
+  headers_file_envvar = getenv(DEBUGINFOD_HEADERS_FILE_ENV_VAR);
+  if (headers_file_envvar != NULL)
+add_headers_from_file(c, headers_file_envvar);
+
   /* Maxsize is valid*/
   if (maxsize > 0)
 {
diff --git a/debuginfod/debuginfod.h.in b/debuginfod/debuginfod.h.in
index 40b1ea00..7d8e4972 100644
--- a/debuginfod/debuginfod.h.in
+++ b/debuginfod/debuginfod.h.in
@@ -38,6 +38,7 @@
 #define DEBUGINFOD_RETRY_LIMIT_ENV_VAR "DEBUGINFOD_RETRY_LIMIT"
 #define DEBUGINFOD_MAXSIZE_ENV_VAR "DEBUGINFOD_MAXSIZE"
 #define DEBUGINFOD_MAXTIME_ENV_VAR "DEBUGINFOD_MAXTIME"
+#define DEBUGINFOD_HEADERS_FILE_ENV_VAR "DEBUGINFOD_HEADERS_FILE"
 
 /* The libdebuginfod soname.  */
 #define DEBUGINFOD_SONAME "@LIBDEBUGINFOD_SONAME@"
diff --git a/doc/ChangeLog b/doc/ChangeLog
index b2bb4890..073023b4 100644
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@@ -1,3 +1,7 @@
+2022-10-18  Daniel Thornburgh  
+
+   * debuginfod_find_debuginfo.3: Document DEBUGINFOD_HEADERS_FILE.
+
 2022-09-02  Frank Ch. Eigler  
 
* debuginfod_find_debuginfo.3: Tweaked debuginfod_get_headers docs.
diff --git a/doc/debuginfod-client-config.7 b/doc/debuginfod-client-config.7
index fecc6038..53d82806 100644
--- a/doc/debuginfod-client-config.7
+++ b/doc/debuginfod-client-config.7
@@ -75,6 +75,13 @@ only small files are downloaded. A value of 0 causes no 
consideration
 for size, and the client may attempt to download a file of any size.
 The default is 0 (infinite size).
 
+.TP
+.B $DEBUGINFOD_HEADERS_FILE
+This environment variable points to a file that supplies headers to
+outbound HTTP requests, one per line. The header lines shouldn't end with
+CRLF, unless that's the system newline convention. Whitespace-only lines
+are skipped.
+
 .SH CACHE
 
 Before each query, the debuginfod client library checks for a need to
diff --git a/doc/debuginfod_find_debuginfo.3 b/doc/debuginfod_find_debuginfo.3
index aebbec3f..3dd83240 100644
--- a/doc/debuginf

Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)

[Daniel Thornburgh via Elfutils-devel]

Hi elfutils-devel@,

I've been working on adding debuginfod support to various LLVM utilities,
while simultaneously setting up production use of debuginfod for a managed
developer environment.

One issue that keeps cropping up is that there's often quite a few places
to get debug files from locally, in addition to various remote backends.
For example, the output of local build systems, prebuilt packages and
tarballs that a developer is working on, etc.

One of the best things about debuginfod is that you can set up a service
once, then point an astonishingly wide array of tools at the server, with
one configuration.

This isn't the case for files available locally, but there is some prior
art: GDB's build ID directory layout (commonly
`/usr/lib/debug/.build-id//`). GDB has a flag to control this (`--with-separate-debug-dir`), but
that flag isn't shared by other tools. For example, binutils supports this
layout, but it simply hardcodes a list of directories to search for, with
no way to extend or override it. LLVM also supports this, but has a
differently named flag for it.

Local files can be served to localhost using a debuginfod server, but this
incurs the overhead of transferring the files over a local socket on first
access, and the much worse overhead of storing an additional copy of the
file on disk in the debuginfod cache. With sufficiently large projects,
this gets pretty rough.

It would be really nice if there were, a DEBUGINFOD_LOCAL_PATH environment
variable that provided a colon-separated list of directories in the GDB
`.build-id//` format to locally fetch files out of before
attempting remote servers. This would allow imbuing local build ID fetching
to tools that wouldn't otherwise support it, with one common configuration
language for how to do it.

I did definitely want to raise this on the mailing list before starting to
implement something like this though, since it increases the scope of
libdebuginfod to include local fetching out of more than just out of its
own cache. It would stretch debuginfod towards a more general "library for
obtaining debug info writ large", rather than a straightforward remote
client library.

Daniel Thornburgh | dth...@google.com

Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)

[Daniel Thornburgh via Elfutils-devel]

On Wed, May 31, 2023 at 3:35 PM Frank Ch. Eigler  wrote:

> > [...]
> > It would be really nice if there were, a DEBUGINFOD_LOCAL_PATH
> environment
> > variable that provided a colon-separated list of directories in the GDB
> > `.build-id//` [...]
>
> Please note that $DEBUGINFOD_URLS can already include file:// URLs
> that identify local filesystems whose directory structure mirrors the
> webapi.  The old-school /usr/lib/debug/.build-id/xx/.debug
> file hierarchy doesn't match that, and of course lacks source code
> entirely.
>

Ah, I had forgotten completely that file URLs worked out of the box
(libcurl, duh).
When we tried that way back when, the issue was just that it actually does
a libcurl fetch
out of that path and saves another copy of the file into the cache.

So I guess, sans the format, the feature request would just be that it
would have a shortcut
for file URLs to produce the path directly in response to e.g. a
debuginfod_find_debuginfo,
rather than making a copy of the file via libcurl.

Does that seem like a reasonable patch?

Daniel Thornburgh | dth...@google.com

Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)

[Daniel Thornburgh via Elfutils-devel]

Hmm, how would the effective behavior of this differ from directly
returning the path? The symlink could become invalid at any time, and it
would become invalid in precisely the same scenarios that the original file
would. A further request would in both cases stat the original file, and if
it were missing, download a new copy into the cache via the usual
mechanisms.

It would make sense if the cache were made to contain a hard link to the
file if it were on the same filesystem as the cache, but that inherits the
usual problems with hard links. It would persist a copy of the file in the
cache though.

On Thu, Jun 1, 2023 at 7:58 AM Frank Ch. Eigler  wrote:

> Hi -
>
> > So I guess, sans the format, the feature request would just be that
> > it would have a shortcut for file URLs to produce the path directly
> > in response to e.g. a debuginfod_find_debuginfo, rather than making
> > a copy of the file via libcurl.
>
> A compromise solution could be for new code to produce a symlink in
> the .cache/debuginfod_client directory that points to the matching
> file:// bit, and return that symlink name/fd to the calling app.
>
> At future accesses, the client can determine if the symlink is
> broken and reject/unlink it.
>
> - FChE
>
>

-- 

Daniel Thornburgh | dth...@google.com

Re: Local Build ID Directory Lookup (DEBUGINFOD_LOCAL_PATH)

[Daniel Thornburgh via Elfutils-devel]

SGTM; I'll see if I can write a patch to do this when I get some spare
cycles.

On Thu, Jun 1, 2023 at 2:21 PM Frank Ch. Eigler  wrote:

> Hi -
>
> > Hmm, how would the effective behavior of this differ from directly
> > returning the path? The symlink could become invalid at any time [...]
>
> Effective behaviour is about the same, but code logic and explanation
> is simpler.
>
> > It would make sense if the cache were made to contain a hard link to the
> > file if it were on the same filesystem as the cache [...]
>
> And this could be a QoI implementation detail: prefer hardlink, fall
> back to symlink.
>
> - FChE
>
>

-- 

Daniel Thornburgh | dth...@google.com

debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

Hello elfutils-devel@

I'm working on a use case for debuginfod (in LLVM) that needs a solution
for authentication and authorization of users when accessing source and
debug information. I've put together a short RFC for how this might work,
based on how git and Docker CLIs handle credentials. It should be fairly
straightforward to implement and to generalize to new credential types.

Please take a look; it'd be good to have a consensus on how this should
work across interested debuginfod implementations before moving forward
towards implementation.

-- 
debuginfod Credential Helper RFCBackground

debuginfod is a simple HTTP-based protocol allowing clients to obtain debug
information from servers. The de-facto standard includes environment
variables for pointing clients at available debuginfod servers, but it
includes no mechanism to provide credentials.

This approach works well for fully open-source projects, but debuginfod is
also particuarly useful for the highly-stripped binaries and constrained
environments found in the embedded space. There, it’s common for licensing
constraints to require access to source and debug information to be
restricted to specific users.
Proposal

debuginfod clients could support a new DEBUGINFOD_CREDENTIAL_HELPER environment
variable. This would provide a command that a debuginfod client could run
to obtain credentials to supply to the server, much like Git or Docker
credential helpers do.

No modifications are proposed to generic debuginfod server implementations,
since specific authentication and authorization decisions are usually quite
domain-specific, and it’s fairly easy to write or configure a custom
debuginfod server to make them.

The proposal also omits any mechanism for the client to interactively
prompt the user for their credentials or to retrieve them from storage;
this is left to the credential helper.
Protocol

The behavior of the credential helpers broadly follows the example set by
Git and Docker.

The DEBUGINFOD_CREDENTIAL_HELPER environment variable contains a string
indicating the command to run. If the string begins with an absolute path,
the command is the verbatim string. Otherwise, the command is the string
prepended with debuginfod-credential-.

Once interpreted, the given command is executed in the shell with one
additional argument to indicate the operation type. This is always get.

The helper reads a description of the requested credential from stdin and
writes a description of the found credential to stdout. Errors may be
reported to stderr.
Credential Format

Credential requests and found credentials are both broadly described using
Git credential helpers’ input/output format
, with some modifications.

Only the http and https protocols are supported, since debuginfod only
operates over HTTP(S).

The url attribute is unsupported; URL components must instead be passed
separately.

An added bearer attribute can supply OAuth2 bearer tokens
 in Base64
. This attribute
is mutually exclusive with username and password.

Daniel Thornburgh | dth...@google.com

Re: debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

>
> I think this could work for a standalone program like debuginfod-find,
> but not for a library like libdebuginfod. I would rather not have to
> fork and exec from libdebuginfod.
>
Could this functionality be made optional? Something a client could call to
fork out to a credential helper, but with a notice on the tin? Or just a
way to pass through credentials to libcurl, and libraries for
parsing/producing the helper format?

>

Can't this be handled through e.g. the underlying libcurl library by
> setting a proxy environment variable so the requests goes through a
> local proxy that is setup to do some kind of authentication
> transparently?

It would be at least somewhat undesirable for any process capable of making
loopback requests to gain access equivalent to any user using debuginfod on
that system. A credential helper would only have the ambient authority
available to the user running the debuginfod client.

That being said, I'm not opposed to this idea of an authenticating proxy,
so long as there's a way of scoping access to it appropriately. I'm pretty
far from a UNIX/Windows networking wizard, so if you know of a reasonable
way to do this, please let me know.


> Or by simply defining the base DEBUGINFOD_URL with
> https://user:p...@debuginfod.example.com/ ?
>
The specific use case we had in mind uses OAuth2 bearer tokens, not
username/password pairs. This is increasingly common for the sorts of cloud
hosting one might like to use for things like debug binaries.

-- 

Daniel Thornburgh | dth...@google.com

Re: debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard  wrote:

> I don't know how people "scope" this. But it feels a little paranoid to
> restrict access to debuginfo and sources. So I wouldn't really mind
> other users also having access.
>
> You don't even need a real httpd proxy, you could even run a federating
> local debuginfod server that knows how to do authorization requests.
>
The only use I know of for a feature like this (which is our use case) is
to allow debuginfod to work with closed source software. Even if most of
the system is open source, there may be binary blobs where manufacturers
may share source/debug info with developers under a restricted license that
requires access control to the information.

> > > Or by simply defining the base DEBUGINFOD_URL with
> > > https://user:p...@debuginfod.example.com/ ?
> > >
> >
> > The specific use case we had in mind uses OAuth2 bearer tokens, not
> > username/password pairs. This is increasingly common for the sorts of
> cloud
> > hosting one might like to use for things like debug binaries.
>
> A bearer token is really just an Authorization header key with a random
> string as value. We already have:
>
> /* Add an outgoing HTTP request  "Header: Value".  Copies string.  */
> int debuginfod_add_http_header (debuginfod_client *client, const char*
> header);
>
> So we could maybe have a DEBUGINFO_HEADERS environment variable that
> then contains something like "Authorization: Bearer mF_9.B5f-4.1JqM"
> Which would simply make sure debuginfod_add_http_header is called with
> that value (or multiple if we can agree on a separator character).
>
That way you can run any program using libdebuginfod and get the
> authorization for free by just running it something like:
>
> export DEBUGINFO_HEADERS="$(credential-helper $DEBUGINFOD_URLS)"
> gdb --args ./hack frob frob
>
> Somewhat simplified, since it assumes you just have one DEBUGINFOD_URL
> that needs the Authorization, but that seems fine, it seems an obscure
> enough feature that it doesn't really matter if other servers get the
> Authorization header too, they will just ignore it and don't even know
> against what other server they could use the Bearer token.
>

Ah, I hadn't really looked much at libdebuginfod's interface yet, but
that's very very interesting. Combining this with the idea above, you could
write a nonce to a file only visible to the given user, then write an
authorizing http proxy on localhost that would make sure the incoming http
connection has the matching nonce. Then, the server could supply whatever
credentials are necessary to any outbound servers it federates to. Then,
you'd just need to pass the nonce in DEBUGINFOD_HEADERS and set
DEBUGINFOD_URLS to the local server.

I'll spend some time trying to prototype this and see if it works out like
I think it would. It would be more work for integrators, but that's
generally what I think you'd want for something that's arguably a pretty
niche feature as far as things go, and a good reference implementation
could also be built that supports credential helpers and could be extended
with whatever access mechanisms you like.


> Would any of the above work for your use case?
>
> Cheers,
>
> Mark
>


-- 

Daniel Thornburgh | dth...@google.com

Re: debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

So, I put together a design with this approach, and it passed a security
review, so the approach broadly seems to work for us.

It came up in review that it'd be considerably more usable to have the
environment variable point to a file: DEBUGINFOD_HEADERS_FILE=. This
would avoid storing credentials in environment variables, and it would
allow you to set up the path to the header file in your shell config at the
beginning of a session.

Would this work for libdebuginfod? We'd also want to standardize on the
format of such a file; probably a newline-separated list of headers in the
format accepted by debuginfod_add_http_header()?

On Fri, Jul 29, 2022 at 2:08 PM Daniel Thornburgh  wrote:

> On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard  wrote:
>
>> I don't know how people "scope" this. But it feels a little paranoid to
>> restrict access to debuginfo and sources. So I wouldn't really mind
>> other users also having access.
>>
>> You don't even need a real httpd proxy, you could even run a federating
>> local debuginfod server that knows how to do authorization requests.
>>
> The only use I know of for a feature like this (which is our use case) is
> to allow debuginfod to work with closed source software. Even if most of
> the system is open source, there may be binary blobs where manufacturers
> may share source/debug info with developers under a restricted license that
> requires access control to the information.
>
>> > > Or by simply defining the base DEBUGINFOD_URL with
>> > > https://user:p...@debuginfod.example.com/ ?
>> > >
>> >
>> > The specific use case we had in mind uses OAuth2 bearer tokens, not
>> > username/password pairs. This is increasingly common for the sorts of
>> cloud
>> > hosting one might like to use for things like debug binaries.
>>
>> A bearer token is really just an Authorization header key with a random
>> string as value. We already have:
>>
>> /* Add an outgoing HTTP request  "Header: Value".  Copies string.  */
>> int debuginfod_add_http_header (debuginfod_client *client, const char*
>> header);
>>
>> So we could maybe have a DEBUGINFO_HEADERS environment variable that
>> then contains something like "Authorization: Bearer mF_9.B5f-4.1JqM"
>> Which would simply make sure debuginfod_add_http_header is called with
>> that value (or multiple if we can agree on a separator character).
>>
> That way you can run any program using libdebuginfod and get the
>> authorization for free by just running it something like:
>>
>> export DEBUGINFO_HEADERS="$(credential-helper $DEBUGINFOD_URLS)"
>> gdb --args ./hack frob frob
>>
>> Somewhat simplified, since it assumes you just have one DEBUGINFOD_URL
>> that needs the Authorization, but that seems fine, it seems an obscure
>> enough feature that it doesn't really matter if other servers get the
>> Authorization header too, they will just ignore it and don't even know
>> against what other server they could use the Bearer token.
>>
>
> Ah, I hadn't really looked much at libdebuginfod's interface yet, but
> that's very very interesting. Combining this with the idea above, you could
> write a nonce to a file only visible to the given user, then write an
> authorizing http proxy on localhost that would make sure the incoming http
> connection has the matching nonce. Then, the server could supply whatever
> credentials are necessary to any outbound servers it federates to. Then,
> you'd just need to pass the nonce in DEBUGINFOD_HEADERS and set
> DEBUGINFOD_URLS to the local server.
>
> I'll spend some time trying to prototype this and see if it works out like
> I think it would. It would be more work for integrators, but that's
> generally what I think you'd want for something that's arguably a pretty
> niche feature as far as things go, and a good reference implementation
> could also be built that supports credential helpers and could be extended
> with whatever access mechanisms you like.
>
>
>> Would any of the above work for your use case?
>>
>> Cheers,
>>
>> Mark
>>
>
>
> --
>
> Daniel Thornburgh | dth...@google.com
>
>

-- 

Daniel Thornburgh | dth...@google.com

Re: debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

On Thu, Aug 4, 2022 at 10:02 AM Mark Wielaard  wrote:

> I wonder if we should generalize that for other DEBUGINFOD_envs. But
> instead of adding more environment variables have a debuginfod control
> file like we already have for cache_clean_interval, max_unused_age and
> cache_miss.
>
> So as an alternative to setting any of the DEBUGINFOD_frob environment
> variables you could put an urls, cache_path, progress, verbose
> retry_limit, timeout, maxtime, maxsize or headers file under
> XDG_CONFIG_HOME (~/.config) debuginfod_client that would be used if the
> corresponding environment variable isn't set.
>
> The downside of course is that it would cause more file stats when
> creating a debuginfod_client handle, but the overhead is probably
> minimal especially if programs just reuse the debuginfod_client
> objects.
>
> Or maybe it should just be one control file that can have entries for
> all of the variables.
>
Generalizing our use case, configuration files help when you're looking to
put permissions on part of the debuginfod configuration. Not sure if that
generalizes beyond supplying headers, but maybe in the future?

I could also see file-based config being useful if some aspect of the
debuginfod configuration can change from moment-to-moment. Environment
variables could be used for that, but it would require either changing
those variables in the calling shell or wrapping each debuginfod client
utility.

Or maybe just if the number of environment variables grows unwieldy.

For the permissions and mutable configuration cases, it would be desirable
to point debuginfod at different paths, so that these could be kept in e.g.
tmpfs. These might be machine generated, which also means there may be
multiple sources of such files. So, something like a
DEBUGINFOD_CONFIG_FILES list might work well there; each file could
contain, say, a list of environment_variable=value pairs, (or a more
debuginfod-specific format), and all the files in the list could be
concatenated together. Then, a service set up in bashrc could append or
prepend its moment-to-moment configuration runfile to the list of config
files.

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. This wouldn't compose as well if you needed to do
hackery to say, remove a source of config from the list, though, as then
you'd have to find and remove n sources of config from n lists.
-- 

Daniel Thornburgh | dth...@google.com

Re: debuginfod Credential Helper RFC

[Daniel Thornburgh via Elfutils-devel]

On Mon, Aug 8, 2022 at 1:41 PM Frank Ch. Eigler  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