Hi, as some of you might know from IRC, the Forums or bugzilla, there is a bug with sandbox/perl which happens on unspecific packages at different times of the emerge process. The error message is always the same: symlink: /usr/lib/perl5/5.8.0/base.pm A good package to reproduce the error is media-libs/gst-plugins-0.6.2-r1 as it borks right before it starts compiling. Notice that I set this bug to "Platform: Sparc" as it seems only to happen on Sparc systems. Thanks to the tipps given by Azarah, I could verify that this isnt a Sandbox issue. Its a Perl problem. And to be exact, its a problem with Automake. (on my System, top shows that the used Automake version is 1.6) From what I saw in /usr/bin/automake-1.6, Automake checks if it can find some required libaries/modules in its $libdir (which is set to /usr/share/automake-1.6/). Snippet from automake-1.6: if (-f ("$libdir/$file")) { # Install the missing file. Symlink if we # can, copy if we must. Note: delete the file # first, in case it is a dangling symlink. $message = "installing `$errfile'"; # Windows Perl will hang if we try to delete a # file that doesn't exist. unlink ($errfile) if -f $errfile; if ($symlink_exists && ! $copy_missing) { if (! symlink ("$libdir/$file", $errfile)) { $suppress = 0; $trailer = "; error while making link: $!"; } } elsif (system ('cp', "$libdir/$file", $errfile)) { $suppress = 0; $trailer = "\n error while copying"; } } And exactly this symlink command is, where the Sandbox catches :-) I tried to fix this by linking/copying the base.pm to $libdir, but it always borked with the same error. Maybe the Perl Team knows a solution for that. My workaround involves patching Automake, which forces it to always copy and never symlink. Actually thats what the comments in the above snippet says: " Symlink if we can, copy if we must.". And to make Sandbox happy, we "must" :-) Patch against /usr/bin/automake-1.6 (dev-lang/perl-5.8.0-r12) follows. If you can reproduce this Sandbox error, please apply the patch and test if it fixes the problem for you. For me it did :-)
Created attachment 18445 [details, diff] Patch against /usr/bin/automake-1.6
The patch worked fine on a fresh install on a U60.
It appears this is not isolated to automake-1.6 I get this while emerging kdemultimedia. Besides running into autoconf flipflops as detailed in bug #30062, automake-1.7 causes problems just after configure that give the ACCESS DENIED: symlink: /usr/lib/perl5/5.8.0/base.pm message, but it doesn't fail there. Here is what I see; Good - your configure finished. Start make now + '[' sparc = hppa ']' + shift + '[' make ']' + export PATH=/usr/kde/3.1/bin:/usr/kde/3.1/bin:/usr/lib/ccache/bin:/usr/lib/dis tcc/bin:/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/usr/local/bin:/opt/b in:/usr/sparc-unknown-linux-gnu/gcc-bin/3.2:/usr/X11R6/bin:/opt/blackdown-jdk-1. 4.1/bin:/opt/blackdown-jdk-1.4.1/jre/bin:/usr/qt/3/bin:/usr/kde/3.1/sbin:/usr/kd e/3.1/bin + PATH=/usr/kde/3.1/bin:/usr/kde/3.1/bin:/usr/lib/ccache/bin:/usr/lib/distcc/bin :/sbin:/usr/sbin:/usr/lib/portage/bin:/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr /sparc-unknown-linux-gnu/gcc-bin/3.2:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.1/bin :/opt/blackdown-jdk-1.4.1/jre/bin:/usr/qt/3/bin:/usr/kde/3.1/sbin:/usr/kde/3.1/b in + debug-print-section make + debug-print 'now in section make' + '[' -z /var/tmp/portage/kdemultimedia-3.1.4-r1/temp ']' + '[' 'now in section make' ']' + '[' '' == on ']' + '[' -n '' ']' + echo 'now in section make' + chmod g+w /var/tmp/portage/kdemultimedia-3.1.4-r1/temp/eclass-debug.log + shift + '[' '' ']' + emake cd . && /bin/sh /var/tmp/portage/kdemultimedia-3.1.4-r1/work/kdemultimedia-3.1.4 /admin/missing --run aclocal-1.7 cd . && \ /bin/sh /var/tmp/portage/kdemultimedia-3.1.4-r1/work/kdemultimedia-3.1.4/admin /missing --run automake-1.7 --foreign Makefile ACCESS DENIED symlink: /usr/lib/perl5/5.8.1/base.pm cd . && perl admin/am_edit Makefile.in cd . && /bin/sh /var/tmp/portage/kdemultimedia-3.1.4-r1/work/kdemultimedia-3.1.4 /admin/missing --run autoconf /bin/sh ./config.status --recheck running /bin/sh ./configure --enable-xaw --enable-ncurses --with-xine-prefix=/u sr --disable-nas --disable-esd --without-vorbis --enable-audio=oss --enable-inte rface=xaw,ncurses --host=sparc---enable-mitshm --with-xinerama --with-qt-dir=/usr/qt/3 --enable-mt --disable-de pendency-tracking --disable-debug --without-debug CC=gcc CFLAGS=-mcpu=ultrasparc -O2 -pipe CXXFLAGS=-mcpu=ultrasparc -O2 -pipe CXX=g++ host_alias=sparc-unknow n-linux-gnu --no-create --no-recursion unknown-linux-gnu --prefix=/usr/kde/3.1 --with-x kdemultimedia goes through and does configure again and actually stars building afterwards. kdemultimedia eventually fails right after compiling and before installing. Below I have included the output from emerge -d kdemultimedia at the point just after it's Makefile sucessfully finishes compiling + shift + '[' '' ']' + cd /var/tmp/portage/kdemultimedia-3.1.4-r1 + touch .compiled + cd build-info + echo '' + echo gcc + echo ' ' + echo '-mcpu=ultrasparc -O2 -pipe' + echo sparc-unknown-linux-gnu + echo g++ + echo '-mcpu=ultrasparc -O2 -pipe' + echo ' >=sys-libs/ncurses-5.2 >=media-sound/cdparanoia-3.9.8 >=media-libs/libv orbis-1.0_beta4 >=media-video/xanim-2.80.1 nas? ( >=media-libs/nas-1.4.1 ) esd? ( >=media-sound/esound-0.2.22 ) motif? ( virtual/motif ) slang? ( >=sys-libs/sla ng-1.4.4 ) >=media-sound/mpg123-0.59r tcltk? ( >=dev-lang/tk-8.0.5-r2 ) >=dev-li bs/glib-1.3.3 oggvorbis? ( media-libs/libvorbis ) >=media-libs/xine-lib-1_beta10 ~kde-base/kde-env-3 sys-devel/automake <sys-devel/autoconf-2.57a sys-devel/ma ke dev-lang/perl ~kde-base/kdelibs-3.1.4 >=x11-libs/qt-3.1' + echo 'nas esd motif slang tcltk oggvorbis cdr' + echo GPL-2 + echo kde-base + echo ' ' + echo kdemultimedia-3.1.4-r1 + echo '' + echo ' cdr? ( app-cdr/cdrtools >=app-cdr/cdrdao-1.1.5 ) ' + echo 3.1 + echo 'sparc crypt cups fbcon foomaticdb gnome mad ncurses png truetype zlib gd bm tcpd pam libwww ssl perl python gtk mozilla cdr scanner crypto emacs gtk2 mai ldir mbox samba ultra1 -avi -encode -gif -java -jpeg -mikmod -motif -mpeg -nls - oss -opengl -pdflib -sdl -spell -xv -xml2 -xmms -berkdb -slang -readline -arts - tetex -tcltk -postgres -X -gpm -esd -imlib -oggvorbis -qt -kde' + set + bzip2 -9 - + cp /usr/portage/kde-base/kdemultimedia/kdemultimedia-3.1.4-r1.ebuild kdemultim edia-3.1.4-r1.ebuild + has nostrip sandbox buildpkg ccache distcc cvs noauto noclean + local x + local me + me=nostrip + shift + '[' sandbox == nostrip ']' + '[' buildpkg == nostrip ']' + '[' ccache == nostrip ']' + '[' distcc == nostrip ']' + '[' cvs == nostrip ']' + '[' noauto == nostrip ']' + '[' noclean == nostrip ']' + return 1 + trap SIGINT SIGQUIT + set +x --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-kdemultimedia-3.1.4-r1-23056.log" symlink: /usr/lib/perl5/5.8.1/base.pm --------------------------------------------------------------------------------
I just tried emerging kdemultimedia-3.1.4-r1 with portage 2.0.48-r5 and none of these problems occured. I've also added dev-portage@gentoo.org to the CC so they can provide any input on sandbox changed between the .48 and .49 series.
Interesting... as this seems only to happen on Sparc, is there any platform specific code in Sandbox which could cause this?
*** Bug 28211 has been marked as a duplicate of this bug. ***
Portage devs, Can you look at this ASAP? If we are unable to find a solution for this soon, I'm going to have to mask the 2.0.49 series on sparc.
I can provide access to a sparc box if needed to help debug, however I can't always replicate problem (seems to happen differently for everyone).
I can verify that using portage .48 fixes this problem. I got reports for this sandbox error from two users on IRC yesterday and the patch helped both. To sum it up, there are three ways to solve this issue right now: 1) Disable sandbox (via SANDBOX_DISABLED or by removing it from FEATURES 2) Use portage .48 3) Apply the above patched to the used automake version (not 1.6 in all cases) BTW, one of the yesterday reported errors happend with Perl 5.8.1. The file it borked on wasnt "base.pm" but the cause was the same.
Reassigning to dev-portage, seems to be a sandbox problem.
Anyone alive in dev-portage team?
I'm willing to make myself and any/all of my sparc hardware available at any time this weekend in the effort to help solve this problem (just let me know ahead of time if it's going to be at a time odd to a person in US EST). If no one is able to help, then please provide details as to what would/may be effected by portage-2.0.49 being masked ASAP.
Well, we might fix it automake side. If we run inside portage, PWORKDIR is set (also used for the portage libtool patches). My perl is not that good though, so if somebody could patch automake 1.6/7, ill add it to the automake ebuilds ...
Do not mask portage without good reason. Sandbox violations to this effect is not a good reason, especially when it's not enabled by default and is turned on. The best solution would be to have someone work on getting sandbox happy on 64bit/non-x86 archs. addpredict is another possible solution as well. As for the list of things that will be affected... Short list: SELinux, TB fixes for -U, merge fixes, distcc, binary features and fixes, USE_EXPAND (xfree), python2.3.
I could make the patches to automake 1.4-1.7 ... if thats an accepted solution.
Can we shut sandbox off via make.globals or something until this is fixed? This seems to be a rather common problem for sparc users.
This could be used to patch automake (correct path to automake): for i in 4 5 6 7; do if [ -f "./automake-1.$i" ]; then sed -i "s/\$symlink_exists\ =\ .*/\$symlink_exists\ =\ 0;/;s/\$copy_missing\ =\ .*/\$copy_missing\ =\ 1;/" ./automake-1.$i fi done
Created attachment 19137 [details] Fix for automake I should remember that formatting of long lines is messed up here ;)
I've started having this problem on my workstation at work when emerging ntp-4.1.2. It happenes when automake is run after the patches are applied and before compilation starts. I edited /usr/bin/automake so that when perl is invoked, it runs through the code in debug mode. Below is the output; main::(/usr/bin/automake:58): my $binary = "$0-1.4"; DB<1> main::(/usr/bin/automake:59): my $binary_1_5 = "$0-1.5"; DB<1> main::(/usr/bin/automake:60): my $binary_1_6 = "$0-1.6"; DB<1> main::(/usr/bin/automake:61): my $binary_1_7 = "$0-1.7"; DB<1> main::(/usr/bin/automake:66): if ($ENV{WANT_AUTOMAKE} eq "") { DB<1> main::(/usr/bin/automake:67): if ($ENV{WANT_AUTOMAKE_1_4}) { DB<1> main::(/usr/bin/automake:80): if ($ENV{WANT_AUTOMAKE} ne '1.4') { DB<1> main::(/usr/bin/automake:81): if (-x $binary_1_7 # user may not have _1_7 ... main::(/usr/bin/automake:82): && (($ENV{WANT_AUTOMAKE} eq '1.7') main::(/usr/bin/automake:83): || (cat_('Makefile.in') =~ /^# Makefile\.in generated by automake (\S+)/ ? $1 : '') ge '1.7' main::(/usr/bin/automake:84): || (cat_('aclocal.m4') =~ /^# aclocal.m4 generated automatically by aclocal (\S+)/ ? $1 : '') ge '1.7' main::(/usr/bin/automake:85): || (cat_('aclocal.m4') =~ /^\s*\[?AM_AUTOMAKE_VERSION\(\[?([^\)]{3})[^\)]*\]?\)/m ? $1 : '') ge '1.7')) { DB<1> main::cat_(/usr/bin/automake:56): sub cat_ { local *F; open F, $_[0] or return; my @l = <F>; wantarray ? @l : join '', @l } DB<1> main::cat_(/usr/bin/automake:56): sub cat_ { local *F; open F, $_[0] or return; my @l = <F>; wantarray ? @l : join '', @l } DB<1> main::cat_(/usr/bin/automake:56): sub cat_ { local *F; open F, $_[0] or return; my @l = <F>; wantarray ? @l : join '', @l } DB<1> main::cat_(/usr/bin/automake:56): sub cat_ { local *F; open F, $_[0] or return; my @l = <F>; wantarray ? @l : join '', @l } DB<1> main::(/usr/bin/automake:86): $ENV{WANT_AUTOMAKE} = '1.7'; # to prevent further "cats" and to enhance consistency (possible cwd etc) DB<1> main::(/usr/bin/automake:87): $binary = $binary_1_7; DB<1> main::(/usr/bin/automake:115): $ENV{WANT_AMWRAPPER_DEBUG} and print STDERR "am-wrapper: will execute <$binary>\n"; DB<1> main::(/usr/bin/automake:117): exec $binary, @ARGV; DB<1> ACCESS DENIED symlink: /usr/lib/perl5/5.8.1/base.pm
An additional note, on sparc64, sandbox is enabled in make.globals by default.
scox, i have a another box you can have access to that has this problem with ntp-4.1.2. find me on IRC tomorrow and I'll set you up.
Thanks to Weeve who gave me access to a couple of sparc boxes, i (think i) managed to find where the problem is. By adding some debug infos on the symlink() wrapper, i saw that (old/new)_canonic contained weird stuff. That's because one (or both) of the arguments passed to symlink() are empty. I've made a patch which will return -EINVAL if either oldpath or newpath is empty. It seems to work on Weeve's boxes, so just lemme know if it also works on your boxes.
Created attachment 19194 [details, diff] patch against libsandbox.c
This patch works for me on my work machine. Can others test/verify?
The checks for this is already canonicalize() side: -- static int canonicalize(const char *path, char *resolved_path) { int old_errno = errno; char *retval; /* If path == NULL, return or we get a segfault */ if (NULL == path) { errno = EINVAL; return -1; } /* Do not try to resolve an empty path */ if ('\0' == path[0]) { errno = old_errno; return 0; } retval = erealpath(path, resolved_path); -- so it might be your fix for this issue: -- 13 Oct 2003; Martin Schlemmer <azarah@gentoo.org> libsandbox.c : Fix a bug in libsandbox.c 's checking in the rename wrapper - it basically only checked the destination patch, and not the source, so we could move a protected file to a unprotected directory, and then delete/modify it. Thanks to Andrea Luzzardi (scox) <al@sig11.org>, bug #30992, for this fix. -- I would rather anyhow prefer canonicalize() to check for this.
Ok, except if the bounds I set it, is not 'strong' enough ...
Ok, I see the issue now - we call before_syscall() with invalid 'file' argument. Jason, please try this patch: -- Index: libsandbox.c =================================================================== RCS file: /home/cvsroot/gentoo-src/portage/src/sandbox-1.1/libsandbox.c,v retrieving revision 1.12 diff -u -p -r1.12 libsandbox.c --- libsandbox.c 13 Oct 2003 19:43:25 -0000 1.12 +++ libsandbox.c 13 Oct 2003 20:53:22 -0000 @@ -1283,6 +1283,11 @@ before_syscall(const char *func, const c int result = 1; sbcontext_t sbcontext; + if (!strlen(file)) { + errno = -EINVAL; + return 0; + } + init_context(&sbcontext); init_env_entries(&(sbcontext.deny_prefixes),
Ok, I've found why the canonicalize() check fails. symlink() uses canonicalize_int(), which is defined by : #define canonicalize_int(path, resolved_path) \ { \ if (0 != canonicalize(path, resolved_path)) \ return -1; \ } However, from canonicalize(): if ('\0' == path[0]) { errno = old_errno; return 0; } In short, if the path is empty, canonicalize() will return 0, and canonicalize_int() will not fail. If we replace "return 0" by "return -1", then it'll work (atleast, here it works).
scox's last comment works for me as well. azarah, if you still want me to test that last patch you put up, can you make it work against 2.0.49-r13? i don't have easy access to portage cvs on the box it needs to be tested on. thanks.
No, before_syscall() should check that. Actually it should check a bit more, and I should cleanup canonicalize not to change errno, but rather just let before_syscall() catch it.
Jason, it should apply, it just got the cvs header. Secondly, its the same fix, just in the correct place, but yes, please just verify it.
On a side note: have anybody tried to check why it make so many calls with invalid path's ?
My problem with the patch was due to white space, and the patch now applies. However it does not fix the symlink error.
Try to change that test to: -- if ((NULL == file) || ('\0' == file)) { errno = EINVAL; return 0; } -- Also, it is in the: -- static int before_syscall(const char *func, const char *file) -- function ?
No luck with that either.
Then I cannot see how the other patch fixes it, as it calls it just earlier. Andrea, want to have a look - I cannot test it currently, and the fix should really go in before_syscall, as the canonical of an empty string is technically and empty string.
Well, the problem is that before_syscall() cannot see that "file" is empty/NULL, because the array we pass to it contains random stuff. That's because, if the path is empty, canonicalize() don't do anything with the char* we pass to it and simply returns canonicalize(const char *path, char *resolved_path) { ... if (NULL == path) { errno = EINVAL; return -1; } A solution would be to initialize to \0 the whole array, by either adding "memset (old_canonic, '\0', SB_PATH_MAX); memset (new_canonic, '\0', SB_PATH_MAX);" inside symlink(), or inside canonicalize(). I tried to do so inside symlink(), and it seems to work.
Created attachment 19217 [details, diff] patch for libsandbox.c This is a combination of Martin's comment #27 and my #37. Seems to work, let me know...
Ok, that looks like the more sane/neat fix - mind adding it (or pasting) generated with 'diff -up' ? Thanks.
Nope, was generated with diff -bu... Here's the output with diff -up : --- libsandbox.c.orig 2003-10-14 12:50:29.000000000 +0200 +++ libsandbox.c 2003-10-14 12:49:50.000000000 +0200 @@ -281,6 +281,9 @@ canonicalize(const char *path, char *res int old_errno = errno; char *retval; + + *resolved_path = '\0'; + /* If path == NULL, return or we get a segfault */ if (NULL == path) { errno = EINVAL; @@ -1283,6 +1286,11 @@ before_syscall(const char *func, const c int result = 1; sbcontext_t sbcontext; + if (!strlen(file)) { + errno = -EINVAL; + return 0; + } + init_context(&sbcontext); init_env_entries(&(sbcontext.deny_prefixes),
The last patch (from diff -up) works for me.
Ok, great. Added to cvs, thanks Andrea! Nick, when ever your are ready.
This last patch solves my xfree 4.3.0-r2 sandbox error.
Last patch works for me too.
What is the plan for getting this patch put into portage?
Please inform me as to when this patch will be included in the next 24 hours or I will be masking all of the portage-2.0.49 series on sparc. I understand that I don't know the portage development lifecycle, but this is rather unfair to our users, especially considering there has been a portage release since this was fixed!!!!
In talking with carpaski and investigating this more, it does appear this patch made it into 2.0.49-r15. The entries for it's addition only showed up in the cvs log for libsandbox.c and not in the installed portage changelog. I've confirmed 2.0.49-r15 works on a box that was experiencing this issue as well. If my $0.02 cents counts, I'm ok with closing the bug. Much thanks n to scox, azarah, bazik and the bug reporters for helping with this :)
fixed
