From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 3034D3857414 for ; Fri, 29 Jul 2022 18:58:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3034D3857414 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 0BA57300066F; Fri, 29 Jul 2022 20:58:06 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A6B9D413CBBB; Fri, 29 Jul 2022 20:58:05 +0200 (CEST) Message-ID: <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org> Subject: Re: debuginfod Credential Helper RFC From: Mark Wielaard To: Daniel Thornburgh Cc: elfutils-devel@sourceware.org Date: Fri, 29 Jul 2022 20:58:05 +0200 In-Reply-To: References: <7e442ae6d3be28043d3c3ecd8a66af011b8dd573.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, HK_OBFDOM, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 18:58:08 -0000 Hi, On Thu, 2022-07-28 at 10:47 -0700, Daniel Thornburgh via Elfutils-devel=20 wrote: > >=20 > > 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. > >=20 >=20 > 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? >=20 > It would be at least somewhat undesirable for any process capable of maki= ng > 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. >=20 > 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 prett= y > 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/ ? > >=20 >=20 > The specific use case we had in mind uses OAuth2 bearer tokens, not > username/password pairs. This is increasingly common for the sorts of clo= ud > 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=3D"$(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