Re: [PATCH v3 1/6] rootfs: introduce wrapper to run commands against a rootfs

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 15.09.25 10:57, Hombourger, Cedric (FT FDS CES LX) wrote:
> On Mon, 2025-09-15 at 10:28 +0200, Jan Kiszka wrote:
>> On 25.06.25 21:37, 'Cedric Hombourger' via isar-users wrote:
>>> "sudo chroot" is used in several places to run commands inside
>>> rootfs
>>> directories constructed by Isar. There are cases where a command
>>> could
>>> be used without elevated privileges as long as special folders such
>>> as
>>> /isar-apt are mounted (they are often referenced as /isar-apt in
>>> configuration files found in the target rootfs). For such cases,
>>> bubblewrap may be used to create a non-privileged namespace (either
>>> in a bare/native environment or within a docker/podman container)
>>> where the command will be executed as if chroot had been used. The
>>> rootfs may also be the host root file-system: this should however
>>> be used with care to avoid host contamination problems (note: Isar
>>> already relies on a number of host tools).
>>
>> Where does this take the commands from then, the host env or some
>> better
>> defined rootfs that is aligned with the target rootfs release-wise?
>> Is
>> that controlled by the caller or implicitly by the wrapper.
> 
> rootfs_cmd is a general-purpose helper and does not select a rootfs of
> its own where it will run commands from. This is left to the caller to
> decide. given a rootfs, it will let bubblewrap create a namespace with
> relevant mappings, optionally chdir to a specified directory and run
> the user-specified command.

So none of the patches 2..6 changes the source rootfs for the command to
run?

> 
>>
>> I have to remind that we cannot blindly use host-side tools on the
>> target rootfs (except for the very basic ones) as the latter may be
>> newer than the former and not necessarily compatible.
> 
> Agreed. if we agree on introducing rootfs_cmd then uses shall be
> audited. Reliance on host-tools shall be kept to a minimum to avoid
> host-contamination problems but also avoid incompatibilities as you
> have correctly noted.
> 
> We can debate whether the 1st user of rootfs_cmd from this patch series
> (using apt to download source packages from a target rootfs) should
> have used apt from / (hopefully a kas-container but not guaranteed) or
> from Isar's host rootfs. With mmdebstrap (used from /) using apt (also
> from /), I felt that it was ok.

Really? mmdebstrap builds an maintains a sid rootfs via a bookworm or
even older toolset?

> 
> If you prefer that I switch to have rootfs_cmd call apt from an Isar
> host rootfs then I can rework the patch series to do so. We may have
> other cases where we need a host tool (pulled into an Isar's host
> rootfs) to operate on a target rootfs.

See my question above: If this series does not change the behavior in
step 1, we can move forward and change the tooling source later on. If
it does already, we should address that in the same run.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/6c970587-5544-4be4-bd57-ec81847dd8aa%40siemens.com.