Hi, Quoting Shengjing Zhu (2020-05-19 05:35:23) > >Your two sentences don't tell me what you'd like sbuild to do. In your > >follow-up email please be specific about what you propose and why it would > >be useful and an improvement over the status-quo. > The second sentence is a possible implementation. Mounting an overlay needs > privileged permission. But the beauty of the unshare backend is that it > doesn't need privilege. So I just propose the fuse-overlayfs.
even the unshare backend needs some privilege. To setup the unshared namespace it needs newuidmap and newgidmap which are suid binaries and thus you briefly work with root privileges (there already were two CVEs against these tools: CVE-2016-6252 and CVE-2018-7169). Also, for fuse-overlayfs to make sense you need an *unpacked* rootfs somewhere. Creating this unpacked rootfs needs superuser privileges or otherwise the ownership information will be all off. So the advantage of using an overlay is: - faster than unpacking a tarball (which usually takes below 2 seconds) The disadvantage of using an overlay is: - root is needed to have the lowerdir unpacked somewhere - if anything fails or gets killed, a stale mount is leftover - additional dependencies - fuse has to be setup (user must be in fuse group) - fuse is not available everywhere (for example inside containers, like Debian CI) - more command line options + associated complexity Thanks! cheers, josch
signature.asc
Description: signature
