Re: debuginfod Credential Helper RFC

[Mark Wielaard <mark@klomp.org>]

Hi,

On Thu, 2022-07-28 at 10:47 -0700, Daniel Thornburgh via Elfutils-devel 
wrote:
> > 
> > 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?

I am not sure how useful an optional feature like this is.

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

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.

> > Or by simply defining the base DEBUGINFOD_URL with
> > https://user:pass@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.

Would any of the above work for your use case?

Cheers,

Mark