Where did rootfs.tar.gz come from, and can we trim it down?

[wking]

The tarball landed in d3e2985 (Add a script to prepare a rootfs for testing, 2015-10-13). It looks like it's mostly BusyBox and symlinks to BusyBox:

$ tar -tvf rootfs.tar.gz | grep busybox | wc -l
234

but there's a lot of other stuff in there too:

$ tar -tvf rootfs.tar.gz | grep -v busybox | wc -l
263

Your BusyBox seems to be dynamically linked:

$ lddtree bin/busybox 
bin/busybox (interpreter => /lib/ld64-uClibc.so.0)
    libc.so.0 => None

So I'd replace it with a statically linked version (that's what Gentoo distributes by default).

We can drop all the /dev stuff, /proc, and /sys because of opencontainers/runtime-spec#164, which is part of v0.1.1:

$ tar -tvf rootfs.tar.gz | grep /dev/
drwxr-xr-x root/root         0 2015-04-28 01:38 ./dev/
crw--w--w- root/root       5,1 2015-04-28 01:38 ./dev/console
lrwxrwxrwx root/root         0 2015-03-01 13:26 ./dev/log -> ../tmp/log
drwxrwxr-x root/root         0 2015-03-01 13:26 ./dev/pts/

/home, /linuxrc (one of the BusyBox links), /media, /mnt, /opt, and /root all look pretty useless, so I'd drop them too.

In wking/oci-gentoo-minimal, I've had good results moving /lib to /lib64, which lets us avoid:

$ tar -tvf rootfs.tar.gz | grep lib64
lrwxrwxrwx root/root         0 2015-04-28 00:45 ./lib64 -> lib
lrwxrwxrwx root/root         0 2015-04-28 00:45 ./usr/lib64 -> lib

although that would depend on you getting a static BusyBox without the /lib/ld64-uClibc.so.0 linking (see earlier comments). In fact, I don't think we'll have any non-BusyBox commands left in a trimmed-down tarball, so you can probably drop all the lib* directories.

Shifting all the BusyBox links into /bin and dropping getconf, ldd, and the iptables-xml symlink would let us drop /usr/bin. You don't seem to be using getconf, ldd, or iptables-xml in your tests.

/usr/sbin is some more BusyBox links, brctl, and some iptables stuff. Unless you're testing nested containers, you shouldn't need the non-BusyBox stuff there. Although both your current BusyBox and Gentoo's stock version include brctl, so you could replace your current brctl with a BusyBox link if you need brctl inside the container.

/sbin has more BusyBox links which I'd move to /bin, and a dozen or so other utilities. The only one that looks useful there is ip, and both your current BusyBox and Gentoo's stock version include ip.

/usr/share is just some udhcpc stuff, which the test bundle can drop in favor of explicit networking setup via ip.

Moving into /etc, I think the only things you need to keep are group, mtab, passwd, and resolv.conf (the last of which can be just a blank file over which you mount the host's version, see here, although that's using obsolete mount syntax).

Anyhow, if any of that sounds reasonable, I'm happy to PR something like this that will setup your rootfs from the current Gentoo stage3.

[zenlint]

@wking @mrunalp ,
I doubt whether the rootfs from busybox can support the basic validating well,

For example, roofs from busybox lacks of libapparmmour.so, and the ps binary in it is not support "ps -Z" cmd, thus, the validating of apparmmour and selinux of specs should be blocked.

Anyway, we can do validating using syscalls from Linux kernel, but I think it should be complicated and resulting the annoying code appeared in the validating tool.

Thanks.

[wking]

On Sat, Dec 05, 2015 at 09:07:31PM -0800, LinZhinan(Zen Lin) wrote:

For example, roofs from busybox lacks of libapparmmour.so, and the
ps binary in it is not support "ps -Z" cmd, thus, the validating of
apparmmour and selinux of specs should be blocked.

Anyway, we can do validating using syscalls from Linux kernel, but I
think it should be complicated and resulting the annoying code
appeared in the validating tool.

I agree that its worth putting tools like that into the rootfs once
we're testing AppArmor (but we don't seem to be doing that yet). But
it's a lot easier to understand what's in the rootfs and why if the
commit adding ‘ps’ and libapparmor.so.* explains that its setting up
for subsequent AppArmor tests.

[mrunalp]

@wking The default came from an extracted docker image. I am +1 to making it more minimal.

[mrunalp]

@zenlinTechnofreak I think it shouldn't be too hard to validate selinux (not sure about apparmore). We can modify the rootfs as required when we get there.

[zenlint]

@mrunalp I am doing investigate about these two validation items, will shared the results later.

[liangchenye]

+1.
And the 'Default Devices and File Systems' in oci spec should be verified in runtimetest, not in bundle test.

[wking]

Closed by opencontainers/runtime-tools#3.