public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Thornburgh <dthorn@google.com>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: debuginfod Credential Helper RFC
Date: Fri, 29 Jul 2022 14:08:12 -0700	[thread overview]
Message-ID: <CAEdiOydX7z23X27ki-YBTOk+OWvdgOTHE2hsd8kfVcHAFr4kHQ@mail.gmail.com> (raw)
In-Reply-To: <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org>

On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard <mark@klomp.org> 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: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.
>

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 | dthorn@google.com

  reply	other threads:[~2022-07-29 21:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26 22:50 Daniel Thornburgh
2022-07-28 16:23 ` Mark Wielaard
2022-07-28 17:47   ` Daniel Thornburgh
2022-07-29 18:58     ` Mark Wielaard
2022-07-29 21:08       ` Daniel Thornburgh [this message]
2022-08-02 20:36         ` Daniel Thornburgh
2022-08-04 17:02           ` Mark Wielaard
2022-08-04 18:04             ` Daniel Thornburgh
2022-08-08 20:41               ` Frank Ch. Eigler
2022-08-09 18:13                 ` Daniel Thornburgh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEdiOydX7z23X27ki-YBTOk+OWvdgOTHE2hsd8kfVcHAFr4kHQ@mail.gmail.com \
    --to=dthorn@google.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).