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

["'cedric.hombourger@siemens.com' via isar-users" <isar-users@googlegroups.com>]

On Mon, 2025-09-15 at 12:04 +0200, Jan Kiszka wrote:
> 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?

patch #2: rootfs_cmd will use / as rootfs (to be discussed/decided if
we would prefer to use an Isar host rootfs instead). Use limited to
"apt-get s--download-only source"

patch #3: does not use rootfs_cmd. this is a preparation step

patch #4: rootfs_cmd will use ${IMAGE_ROOTFS} to query the dpkg
database of the image

patch #5: does introduce/use rootfs_cmd. creating a folder and file as
a regular user before we "sudo mmdebstrap" so that the created files
are owned by our calling user and not root

patch #6: a somewhat similar story than #5. This patch does not use
rootfs_cmd but addresses some file ownership "problems"

in summary, only #2 and #4 are using rootfs_cmd
the whole series is an attempt to require less elevated privileges than
we currently are

> 
> > 
> > > 
> > > 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?

strace on a (manual) mmdebstrap run on trixie to create a bookworm
rootfs suggests that it *does* use apt from the host (trixie):

[pid 2055141] execve("/usr/bin/apt-get", ["apt-get", "-o",
"Dir::Bin::dpkg=env", "-o", "DPkg::Options::=--unset=TMPDIR", "-o",
"DPkg::Options::=dpkg", "--yes", "install", "-oAPT::Status-Fd=7", "-
oDpkg::Use-Pty=false", "apt", "?narrow(?or(?archive(^bookworm$)"...],
0x5cf908e87f60 /* 20 vars */) = 0

It appears to use chroot to run some (selected) dpkg --install commands
but not to run apt

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

I hope the above answers clarify. Do let me know if the above findings
give us a new direction to work towards.

> 
> Jan
> 

-- 
Cedric Hombourger
Siemens AG
www.siemens.com

-- 
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/98bd6b37a64eb32f1e42488625e9fd944d1e10ff.camel%40siemens.com.