It seems that the sandbox compares fopen param against "r" only, thinking that "rt" would write the file (which it of course doesn't). I got my build to proceed after changing "rt" to "r" for Linux but the better cure would be to fix portage. Especially since "rb"/"rt" is the preferred way for portable code. Reproducible: Always Steps to Reproduce: 1. Make a program that uses fopen("rt") outside of the portage sandbox (i.e. read in some system header) 2. Make that program a part of the build process. 3. Try to emerge the formed package. 4. Should fail in "open_wr" violation report. Actual Results: "open_wr" violation report doing "emerge luax". Don't have the log available (sorry!) and i already fixed the case by changing "rt"->"r". Expected Results: succesful emerge If you want, i can easily "unfix" my package so it produces this bug. However, i would need other help to bring in the package to Gentoo guidelines (i.e. locating of the various files etc.). If you can point a person to help me with that, i would be very grateful. A little handtaking, and we'll have yet another package for emerge. :) -ak
sandbox fix, Az?
I also got this messages: ----- ACCESS VIOLATION SUMMARY ----- LOG FILE = "/tmp/sandbox-gettext-0.12.1-652.log" open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps open_wr: /proc/self/maps -------------------------------------------------------------------
meder: your bug is completely unrelated to this one ... please search bugzilla to find the real bug you're experiencing (hint it's a configuration problem on your side)
I've looked through the standards (SUSv2, SUSv3, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992) and there is no mention at all of "rt" being valid for fopen(). It appears that "rb" is an alternative to "r" for systems that support text-based and binary-based file access. There is no such thing as "rt", so I believe that the package you're porting is written incorrectly. Nonetheless, there are references on the web that suggest "rt", so maybe that's an extension implemented on DOS and/or Windows platforms. Since it's read-only we can probably add this extra check to portage. If it were "wt" then we would have a problem since the application would be expecting special support not available in glibc. I'll attach the appropriate patch to the sandbox code and reassigned to dev-portage for application. I have no idea which libsandbox.c is currently in use so I patched all of them.
Created attachment 34495 [details, diff] patch to allow fopen("rt") in sandbox
See bug 58240 for a more general patch. There are other undocumented modifiers which are in use (even in use by glibc), and even more annoyingly, they may be used in combinations and in different orders.
Is in portage-2.0.51.19.
