all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Léo Le Bouter" <lle-bout@zaclys.net>, 47614@debbugs.gnu.org
Subject: bug#47614: [security] Chunked store references in .zo files in Racket 8
Date: Tue, 06 Apr 2021 17:27:53 -0400	[thread overview]
Message-ID: <87tuojqf0r.fsf@netris.org> (raw)
In-Reply-To: <e9234acf1e9dff8e5a0fc0ff078fc9e2f201e9a4.camel@zaclys.net>

Hi Léo,

Léo Le Bouter <lle-bout@zaclys.net> writes:

> 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).

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.

For example, when Emacs stats a file, there's no way to automatically
determine which view of the file system to use for that file lookup.  If
the file being stat'd is a file that the user asked to look at, it
should use the user's view of the file system.  If Emacs is trying to
load one of its own dependent libraries, it should see the file system
view associated with the dependencies of Emacs.  If some code in
GnuTLS's shared library (loaded by Emacs) performs a file lookup, it
should see the GnuTLS file system view.  See the problem?

I've come to think that the Guix approach is the most "correct"
approach, given the APIs that our existing body of software was written
for.  (If we rewrote our software from scratch with different APIs, we
would have more options here, but that would be crazy :)

> OTOH, what would be wrong with replacing hashes directly without
> expecting them to be next to anything else?

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.

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.

What do you think?

      Thanks,
        Mark




  reply	other threads:[~2021-04-06 21:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06 11:06 bug#47614: [security] Chunked store references in .zo files in Racket 8 Mark H Weaver
2021-04-06 17:39 ` Léo Le Bouter via Bug reports for GNU Guix
2021-04-06 21:27   ` Mark H Weaver [this message]
2021-04-06 22:18     ` Léo Le Bouter via Bug reports for GNU Guix
2021-04-13 21:27       ` Mark H Weaver
  -- strict thread matches above, loose matches on Subject: below --
2021-04-07  1:38 Racket 8 and store references (was [security] Chunked store references in .zo files in Racket 8 #47614) Philip McGrath
2021-04-07  1:48 ` bug#47614: [security] Chunked store references in .zo files in Racket 8 #47614 Philip McGrath
2021-04-16 15:46   ` bug#47614: [security] Chunked store references in .zo files in Racket 8 Ludovic Courtès
2021-04-16 19:46     ` Philip McGrath
2021-04-17  9:25     ` Mark H Weaver

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=87tuojqf0r.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=47614@debbugs.gnu.org \
    --cc=lle-bout@zaclys.net \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.