Idea (draft): Let libsandbox know all the files provided by packages in *DEPEND and system set, and deny or report access to files provided by packages the package in question does not explicitly (*DEPEND) or implicitly (system set) depend on. AFAIK, other distros do something like this for each binary package to be built: *) Set up some virtual linux (vhost, xen, vmware?, ...). *) Put all (and only) the required packages on that machine, so the new package cannot find any implicit dependency during build. *) Build the new package and make the binary.
debian and redhat use chroots for building. In prefix this would allow precise control over what is taken from the host OS and what not. I think only DEPEND should be considered, as RDEPEND and PDEPEND can never be reliably detected during build, if they are there, then that is technically just "pure luck". So they shouldn't be in during compiling, probably RDEPEND should be in in case src_test is run.
This is unlikely to work. The first problem is that even when using --as-needed, gcc will open unrelated libraries to check for symbols, which would add to the noise in the output. Also, it's very hard (near to impossible) to distinguish between build-time dependency of the package $foo being built and the package $bar which is used at build-time (which might or might not be a build-time dependency of $foo). Simple example can be this: you got your system configured for distcc; distcc was built with zeroconf USE flag. When you build $foo, you'll certainly see these files to be open and read: - /usr/bin/distcc: it's not a build-time dependency of $foo, it's something you set up to use; - libavahi-client.so.3 (or whatever soname): it's a run-time dependency of distcc; - libdbus-1.so.3 (or whatever soname): it's a run-time dependency of libavahi-client. Not only it would report a package that is totally unrelated to $foo (distcc), but it also reports a package that is distant 1 from that, and a package distant 2 from that. Don't even think of what might happen if a package uses doxygen and LaTex, to consider the amount of files opened and read. So if you want to use this to _report_ possible missing dependencies (implicit deps are not the problem; missing deps are), you'd probably get a SNR ratio near 0.09. If you een want to prevent access to files for packages that are not in DEPEND... you're going to kill a lot of stuff in the middle, like dbus as said above. And that's with a setup issue, I don't even want to start thinking about a package calling java (and yeah there are packages doing so).
How do other distros know which packages to put into the chroot/vhost/xen/whatever environment to build their binary packages then ?
comparing other package systems isnt entirely applicable. for the source (spec/deb/whatever) files, they do exactly like we do: they enumerate required packages by hand. for exact libraries (NEEDED), they scan the compiled objects (just like we do)
