Index | Thread | Search

From:
"Theo de Raadt" <deraadt@openbsd.org>
Subject:
Re: Enable VA-API in graphics/ffmpeg
To:
Landry Breuil <landry@openbsd.org>
Cc:
José Maldonado <josemald89@gmail.com>, ports@openbsd.org
Date:
Sun, 28 Jul 2024 08:49:26 -0600

Download raw body.

Thread
  • Jan Stary:

    Enable VA-API in graphics/ffmpeg

  • Landry Breuil <landry@openbsd.org> wrote:
    
    > thanks, that's a start, because it makes us understand what files are
    > opened by which process.
    > 
    > But you do realize this adds lots of capacities to those process types
    > that arent needed right now, thus shouldnt be added.
    
    That is correct.  What's being proposed is very close to the same
    thing as just deleting the pledge calls entirely.  These two choices
    are very close to each other:
    
    +           pledge("everything")
    -           pledge("something")
    
    > The right process is to figure out _what_ codepaths open those
    > libs/paths, and try to move those initializations *before* sandboxing,
    > so that adding those capacities isnt needed. Preloading libs before
    > sandboxing is a trick that has been done before (cf
    > https://phabricator.services.mozilla.com/D193353 /
    > https://bugzilla.mozilla.org/show_bug.cgi?id=1856301) now we need to add
    > a bit more libs, make sure subsequent dlopens finds the preloaded lib,
    > and do the same for the drm device fd. Right now wpath is needed because
    > it tries to open /dev/dri/renderD128 read-write after sandboxing, doing
    > that before sandboxing is the way to go.
    
    Indeed.  this is how a majority of OpenBSD base programs were adapted
    to pledge.  We even came up for the process, "hoisting", where the
    security-requiring sections are lifted higher, or earlier, in the code.
    
    
    
  • Jan Stary:

    Enable VA-API in graphics/ffmpeg