From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 12F9F3856DE8 for ; Tue, 9 Aug 2022 18:13:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 12F9F3856DE8 Received: by mail-ej1-x62b.google.com with SMTP id m4so23647989ejr.3 for ; Tue, 09 Aug 2022 11:13:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=u14B7tkhr1h8fgdlie4/yB6UwOVifOx5WPaA5plDWCk=; b=Hlg3sI86UFVnJiycnh1JgJm40EQnI2kEscwAuzFkW/9igsA6DB4CzLRRR+c+fNDymh 6OB4eEQNRTe2gq1VtdUfK+R5SuyiAOVdLw/ldWSAbr67C4QQWcgp0/rfgyU24rWrUnlK RzxQK2bVR/i8mdjpN7NgxlsRWWo+n41mMFBVGRgfEkE5Vj/M4yIEcnNwFREhBfO43GNw M6bZcm4wiDEplbpl7HGfzonILjNHSTkGYTkDTuWUmWXySQZxVbEtlJOJhz8wxuvQzFUY LG3eydtvxvHUeghGmZcWf8yfI3cxzHFhw9hQ6dx/Z4cyfjzG4rcXtA6piinOZ5E9aSwQ wpiw== X-Gm-Message-State: ACgBeo2H7zqkgIIAqW9yZ2BawAJuXHYxyxJ7dlDwqQHkLKjHouHrvNL0 PeaDYMBm3RZCe0/s7Bv7X8R5t8NC7td2XXB0wZjH7husWKc= X-Google-Smtp-Source: AA6agR605FII/9U7QUMowcCoYS6tKuXcekHgNArGh2kabs5tM2YqRhzA65ddtIYmgwSObwAuh5wIZMi+dNlyRsH4yms= X-Received: by 2002:a17:907:a057:b0:730:a2d8:d5ac with SMTP id gz23-20020a170907a05700b00730a2d8d5acmr17728569ejc.764.1660068833667; Tue, 09 Aug 2022 11:13:53 -0700 (PDT) MIME-Version: 1.0 References: <7e442ae6d3be28043d3c3ecd8a66af011b8dd573.camel@klomp.org> <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org> <025de8a2c25112e902cc330199b9d0ebb61fbaf6.camel@klomp.org> <20220808204143.GC16198@redhat.com> In-Reply-To: <20220808204143.GC16198@redhat.com> From: Daniel Thornburgh Date: Tue, 9 Aug 2022 11:13:42 -0700 Message-ID: Subject: Re: debuginfod Credential Helper RFC To: "Frank Ch. Eigler" Cc: Mark Wielaard , elfutils-devel@sourceware.org X-Spam-Status: No, score=-17.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 09 Aug 2022 18:13:57 -0000 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 | dthorn@google.com