multibuild.eclass uses /dev/fd. Mac OS X seatbelt sandbox must be adjusted to allow access. Otherwise xorg and python ebuild fail horribly: setuptools ebuild aborts noisily while reporting: >>> Preparing source in /usr/local/gentoo/var/tmp/portage/dev-python/setuptools-0.6.33/work/distribute-0.6.33 ... * Applying setuptools-0.6_rc7-noexe.patch ... [ ok ] * Applying distribute-0.6.16-fix_deprecation_warnings.patch ... [ ok ] * Will copy sources from /usr/local/gentoo/var/tmp/portage/dev-python/setuptools-0.6.33/work/distribute-0.6.33 /usr/local/gentoo/var/tmp/portage/dev-python/setuptools-0.6.33/temp/environment: line 2450: /dev/fd/62: Operation not permitted /usr/local/gentoo/var/tmp/portage/dev-python/setuptools-0.6.33/temp/environment: line 2450: /dev/fd/60: Operation not permitted >>> Source prepared. Even worse: beautifulsoup and xcb-proto ebuild build and merge find but don't install any files. Indication what's wrong is minimal: >>> Install xcb-proto-1.8-r1 into /usr/local/gentoo/var/tmp/portage/x11-proto/xcb-proto-1.8-r1/image/ category x11-proto /usr/local/gentoo/var/tmp/portage/x11-proto/xcb-proto-1.8-r1/temp/environment: line 3188: /dev/fd/62: Operation not permitted >>> Completed installing xcb-proto-1.8-r1 into /usr/local/gentoo/var/tmp/portage/x11-proto/xcb-proto-1.8-r1/image/ Reproducible: Always
Created attachment 342382 [details, diff] allow access to /dev/fd
Created attachment 342384 [details] streamline sanbox rules
perhaps it's time to define a variable in make.globals or something that contains a list of paths that's at runtime added to the config? That way we don't rely on portage version for having the correct rules.
... and then set it via a profile-specific make.defaults, e.g. in profiles/prefix/darwin? I totally agree and will look into it.
Created attachment 342430 [details, diff] unfinished: store seatbelt profile and configuration in make.globals Here's my first crack at make.globals: It's certainly possible to move the list of allowable files/directories there. Once I was at it, I also tried putting the whole profile there. There's one issue with that: Newlines are eaten by the code parsing make.globals. seatbelt doesn't really need them, but it makes me wonder, what other specialities make.globals has. What do I have to look out for? Does it make sense to put the seatbelt profile into make.globals anyway? It certainly makes it more accessiable for debugging by the user. Also, I'd like to see if it can be put into make.defaults as well, so it can be distributed with the portage tree. I wonder if there's possibly a security issue with that (stuff downloaded from the net possibly allowing write access by ebuilds to my system...). Also, the code now depends on variables that might or might not be set. I'd like to inform the user if something seems fishy. Is it legitimate to use writemsg in doebuild.py:spawn()? How and where else would I possibly go about checking if certain variables are defined in make.globals and inform the user about problems? Comments welcome.
Created attachment 342656 [details, diff] store writeable paths for seatbelt sandbox in make.globals This patch takes care of all the issues: - it allows access to /dev/fd/* - it streamlines sandbox rules - it stores all the paths in two variables in make.globals - the seatbelt profile template remains in const.py for now - only one writemsg remains and its output looks okay to me As far as I'm concerned, this can be applied. I've thought about documenting those variables in a man page entry but didn't because this doesn't really seem like end-user-functionality to me. Moving those variables into make.defaults inside the portage tree is also possible. One funny thing I've noticed: A seatbelt rule such as this: (allow file-write-data) with no literal, regex or subpath statements actually allows the operation globally. Setting either of those make.globals variables to empty will result in such a rule and therefore effectively disable restrictions on that operation.
Created attachment 342658 [details, diff] same as before against latest git Here it is again against latest git. I just realised that the previous patches were against vanilla 21688 without the patch from https://bugs.gentoo.org/show_bug.cgi?id=443444.
thanks, this is in 2.2.01.21864
