Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    5bc5326a
    runtime: Adjust fallback behaviour when taking files from provider · 5bc5326a
    Simon McVittie authored
    
    Previously, we assumed that if OS files on the provider are in a
    location that is not /usr or a related directory, for example if the OS
    has /lib/ld-linux.so.2 -> /some/odd/path/i386/ld.so, then they will
    appear below the same path_in_container_ns as /usr, for example
    /run/host/some/odd/path/i386/ld.so. However, nothing sets this up for
    directories other than /usr, /lib*, /bin, /sbin and /etc, so it's
    a bad assumption.
    
    A previous commit handled /etc by redirecting it to /run/host/etc,
    /run/parent/etc or /run/gfx/etc as appropriate, so we don't need to
    worry about that here.
    
    For the rest, assume that if they appear in the container at all,
    they'll appear at a path that matches their location in the provider.
    For the common case where provider = host, which is the only one where
    we really need to support non-FHS layouts, this means that users can
    work around lack of explicit support for a particular non-FHS directory
    with something like PRESSURE_VESSEL_FILESYSTEMS_RO=/some/odd/path.
    
    In particular, if we didn't have explicit support for /nix, NixOS users
    would have been able to use that workaround to get it mounted.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    5bc5326a
    History
    runtime: Adjust fallback behaviour when taking files from provider
    Simon McVittie authored
    
    Previously, we assumed that if OS files on the provider are in a
    location that is not /usr or a related directory, for example if the OS
    has /lib/ld-linux.so.2 -> /some/odd/path/i386/ld.so, then they will
    appear below the same path_in_container_ns as /usr, for example
    /run/host/some/odd/path/i386/ld.so. However, nothing sets this up for
    directories other than /usr, /lib*, /bin, /sbin and /etc, so it's
    a bad assumption.
    
    A previous commit handled /etc by redirecting it to /run/host/etc,
    /run/parent/etc or /run/gfx/etc as appropriate, so we don't need to
    worry about that here.
    
    For the rest, assume that if they appear in the container at all,
    they'll appear at a path that matches their location in the provider.
    For the common case where provider = host, which is the only one where
    we really need to support non-FHS layouts, this means that users can
    work around lack of explicit support for a particular non-FHS directory
    with something like PRESSURE_VESSEL_FILESYSTEMS_RO=/some/odd/path.
    
    In particular, if we didn't have explicit support for /nix, NixOS users
    would have been able to use that workaround to get it mounted.
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>