From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 17:29:03 2021 Received: (at 47614) by debbugs.gnu.org; 13 Apr 2021 21:29:03 +0000 Received: from localhost ([127.0.0.1]:32788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWQak-00045Y-QA for submit@debbugs.gnu.org; Tue, 13 Apr 2021 17:29:03 -0400 Received: from world.peace.net ([64.112.178.59]:35854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWQai-000451-MQ for 47614@debbugs.gnu.org; Tue, 13 Apr 2021 17:29:01 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWQac-0001MN-09; Tue, 13 Apr 2021 17:28:54 -0400 From: Mark H Weaver To: =?utf-8?Q?L=C3=A9o?= Le Bouter , 47614@debbugs.gnu.org Subject: Re: bug#47614: [security] Chunked store references in .zo files in Racket 8 In-Reply-To: <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@zaclys.net> References: <87k0pf7jti.fsf@netris.org> <87tuojqf0r.fsf@netris.org> <9b7e130d5b993a0376698e07f5f9346a5775604f.camel@zaclys.net> Date: Tue, 13 Apr 2021 17:27:11 -0400 Message-ID: <87a6q1swmt.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 47614 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi L=C3=A9o, L=C3=A9o Le Bouter writes: > On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote: >>=20 >> L=C3=A9o Le Bouter writes: >>=20 >> > I think that probably replacing arbitrary paths in built binaries >> > is a risky and maybe unreliable engineering choice and that >> > mechanisms inside kernels should be preferred to give processes a >> > different view of the file system (retaining the path but changing >> > the contents of the folder). >>=20 >> I've had thoughts along these lines myself, but I don't think it can >> work properly. The fundamental problem is that in general, each >> process includes shared objects from many different Guix packages. >> There would need to be a mechanism to determine, when looking up a >> file, which Guix package that file lookup was originating from (or >> whether it was coming from a file name provided by the user), in >> order to determine which "view of the file system" to use for >> purposes of that lookup. There's no way to determine this reliably. > > Is it really that big a deal if it's impossible to access the ungrafted > /gnu/store item?=20 It's a fair question, and reasonable people may disagree, but I would personally find it quite troubling to not be able to confidently and straightforwardly examine files in /gnu/store without wondering if my tools were showing me something else. Anyway, this would be a very radical change in Guix, and I think this bug report is not the best place to discuss it. If you'd like to persue this idea further, I suggest starting a thread on 'guix-devel'. >> > OTOH, what would be wrong with replacing hashes directly without >> > expecting them to be next to anything else? >>=20 >> Personally, I would find that limitation acceptable, and that's >> fairly close to what our grafter originally did (although my fast >> grafting code always assumed that a "-" would follow the hash). >> However, we've since become accustomed to being able to have >> replacements with different version numbers. That's a nice feature. > > Version numbers, agree, I didnt realize that replacing the program name > and version was also required there. However I am thinking we could > fake (or alias, with a symlink) the version in the store item name on > purpose so that it remains the same while pointing to something with a > newer version, it would actually be better that way because we wouldnt > have to think about retaining identical version string length during > grafts. This idea is the subject of , and it's certainly doable. The main disadvantage I see is that file system lookups in grafted store items would become less efficient, because more symbolic links would need to be followed. Anyway, if you'd like to persue this idea further, let's discuss it in that other bug report. >> Anyway, I doubt that imposing such a limitation would adequately >> solve the problem here of chunked references in Racket 8, because I >> suspect that Racket 8 could split store references at arbitrary >> points in the string. I doubt that we can safely assume that the >> hash component of store references will be stored contiguously in >> *.zo files. > > Indeed, is the format for the string references in .zo files documented > anywhere? Is there hope you think we can recognize and automatically > rewrite these strings? According to Philip McGrath, "The .zo format is intentionally undocumented and subject to breaking change, including from different compilation options." See . Thanks, Mark