With a certain base image, the derived image's `PATH` is "regressing" to the base image's one.

[gwangmu]

Hello, and thank you for maintaining Enroot.

Recently, I received a user report that says Enroot behaves differently from Podman. Specifically, this user built a container image using Podman based on SLE BCI SP6 and confirmed that the resulting image works fine on Podman. But they discovered that the same image (exported as SquashFS) doesn't work on Enroot because it couldn't find most libraries.

We dug deeper and found out that the environment variable PATH is weirdly "regressing" to the base image's one on Enroot, while this doesn't happen on Podman. I've attached a small reproducer below.

gwangmu@gwangmu-pc:~/Scratch$ cat >Containerfile
FROM registry.suse.com/bci/bci-base:15.6.47.23.28 
ENV PATH="hahahaha:$PATH"
^C

gwangmu@gwangmu-pc:~/Scratch$ podman build -f Containerfile -t test
STEP 1/2: FROM registry.suse.com/bci/bci-base:15.6.47.23.28
Trying to pull registry.suse.com/bci/bci-base:15.6.47.23.28...
Getting image source signatures
Copying blob 8ca46d9f8f47 done   | 
Copying config 5dc4f47e62 done   | 
Writing manifest to image destination
STEP 2/2: ENV PATH="hahahaha:$PATH"
COMMIT test
--> 462dab5944c2
Successfully tagged localhost/test:latest
462dab5944c2bc05c4edf0b27c8c3a03b666d0163afb9f5e42c21f8863ddbe61

gwangmu@gwangmu-pc:~/Scratch$ podman run --rm -it test sh -c 'echo $PATH'
hahahaha:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Meanwhile with Enroot,

gwangmu@gwangmu-pc:~/Scratch$ enroot import podman://test
[INFO] Fetching imageb290d9701b89046e24cb5c876eeff5c3e63697a13061694b76d230e021dbe2a7[INFO] Extracting image content...
[INFO] Creating squashfs filesystem...Parallel mksquashfs: Using 16 processors
Creating 4.0 filesystem on /home/gwangmu/Scratch/amd_ticket/test.sqsh, block size 131072.
[=====================================================================================================================================/] 3587/3587 100%Exportable Squashfs 4.0 filesystem, lzo compressed, data block size 131072
    uncompressed data, compressed metadata, compressed fragments,
    compressed xattrs, compressed ids
    duplicates are removed
Filesystem size 103450.91 Kbytes (101.03 Mbytes)
    85.86% of uncompressed filesystem size (120492.78 Kbytes)
Inode table size 62067 bytes (60.61 Kbytes)
    32.88% of uncompressed inode table size (188778 bytes)
Directory table size 65598 bytes (64.06 Kbytes)
    56.59% of uncompressed directory table size (115911 bytes)
Number of duplicate files found 438
Number of inodes 5103
Number of files 2904
Number of fragments 227
Number of symbolic links 925
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1274
Number of hard-links 801
Number of ids (unique uids + gids) 1
Number of uids 1
    root (0)
Number of gids 1
    root (0)

gwangmu@gwangmu-pc:~/Scratch$ enroot start test.sqsh sh -c 'echo $PATH'
enroot-switchroot: failed to change directory: /home/gwangmu: No such file or directory
/usr/local/bin:/usr/bin:/bin

This reproducer only works with a specific container image, such as the one used above. Other generic images, such as ubuntu, didn't exhibit the same problem. I wonder whether this is one of "known issues," and if not, whether (or how) it should be fixed.

Thank you very much.

[gwangmu]

Also there was a suspicious error message right after the Enroot startup

enroot-switchroot: failed to change directory: /home/gwangmu: No such file or directory

I'm also wondering if this is related to the issue.