From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109199 invoked by alias); 21 Nov 2019 16:37:56 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 109179 invoked by uid 89); 21 Nov 2019 16:37:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=selectively, white X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Nov 2019 16:37:54 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 73BD030014AB; Thu, 21 Nov 2019 17:37:52 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 202AB413CEAA; Thu, 21 Nov 2019 17:37:52 +0100 (CET) Message-ID: Subject: Re: patch 2/2 debuginfod server etc. From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org, amerey@redhat.com Date: Thu, 21 Nov 2019 16:37:00 -0000 In-Reply-To: <20191121155751.GE12001@redhat.com> References: <8d0b26865cc18838c24ea57c09f4ee5af713af16.camel@klomp.org> <20191114122953.GC873@redhat.com> <20191118184108.GC2880@redhat.com> <52e9358695f8486af6e4e467660c971a1e97c02f.camel@klomp.org> <20191119161348.GB4911@redhat.com> <20191119201128.GA3494@wildebeest.org> <20191119211503.GF4911@redhat.com> <7f1273e6dbfd52b95e9f8e86f6096fe46e800745.camel@klomp.org> <770d563fc3cb0681678c919024edcd5ce13d874a.camel@klomp.org> <20191121155751.GE12001@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00200.txt.bz2 Hi Frank, On Thu, 2019-11-21 at 10:57 -0500, Frank Ch. Eigler wrote: > > It simply splits the paths into those scanned for rpms, those scanned > > for files and (optional) paths that are extra trusted prefixes for > > source files. The paths that are scanned for files are trusted source > > prefixes by default. There is a new option to also remove those using > > -N, --no-files-sources). And you can switch back to allowing all files > > on the file system with -A, --all-sources. >=20 > If the perceived problem is that build tree scans (-F) may contain > binaries that refer to source files that are not appropriate for > later sharing, then IMO this is too much change, and unnecessarily > complicates other valid usage. Yes, that (and references to any other source files, whether those scanned by -F or -R or simply because they are reachable on the file system) is the problem that is being solved. > If you are certain that source file censorship needs to be in the > code, I'd do it instead by adding just one option -S PATH to the code, > which would act like a whitelist for -F source file retrievals. > (There is no point to filtering -R rpm source files; those are only > serviced from other indexed RPMs.) By default all -F directories are already whitelisted. -S is just for extra places where source could be found. > So: >=20 > debuginfod -S /usr/src/debug -S /usr/include -F PATH1 PATH2 ... PATHn >=20 > would restrict -F source service to the given paths, and >=20 > debuginfod -F PATH1 PATH2=20 >=20 > would not, because normal people have trustworthy build systems etc. I guess we differ on how trustworthy generated debug files are. But in my patch by default any files under PATH1 and PATH2 would not be restricted by default (unless -N is given). > If you like, the above two -S paths can be made part of the default > for the debuginfod.service. There is no need to compile-in a > restrictive default (such as making the non-S case mean "no source > for > you!"), because there is no compiled-in default for any file paths to > search, so this issue just does not arise. >=20 > Would you like me to prototype this quickly? What I would like is: - By default only restrict the files served to those under the directory that the file-scanner uses (that is why I split the -R and -F cases). - Have a more restrictive mode that simply doesn't add anything to the sources white list (that is -N in my patch). - Have an anything goes mode (that is -A in my patch). - Be able to whitelist more selectively (that is -S). If I understand you correctly (given your other email in reply to why adding globbing support isn't enough), you also want a mode where all extra arguments on the command line are interpreted as "scannable" (either file based or rpm based). So I think the real issue is the splitting of -R and -F argument parsing. If that is the case, maybe just picking a default for how to interpret the extra arguments, as dirs for the file scanner or dirs for the rpm scanner or both, might make us both happy? Cheers, Mark