Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 26932 - sun-jdk sandbox violation
Summary: sun-jdk sandbox violation
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Adrian Almenar
URL:
Whiteboard:
Keywords:
Depends on: 26683
Blocks:
  Show dependency tree
 
Reported: 2003-08-19 09:43 UTC by Andreas Simon
Modified: 2003-09-10 00:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Simon 2003-08-19 09:43:01 UTC
# emerge sun-jdk 
>>> emerge (14 of 26) dev-java/sun-jdk-1.4.2 to / 
>>> Unpacking source... 
tail: +507: No such file or directory 
ACCESS DENIED  open_wr:   /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin 
./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin: Permission 
denied 
./install.sfx: line 2: syntax error near unexpected token `)' 
$aKsj2sdk1.4.2/include/jvmpi.hUT)
Comment 1 Andreas Simon 2003-08-19 09:43:01 UTC
# emerge sun-jdk 
>>> emerge (14 of 26) dev-java/sun-jdk-1.4.2 to / 
>>> Unpacking source... 
tail: +507: No such file or directory 
ACCESS DENIED  open_wr:   /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin 
./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin: Permission 
denied 
./install.sfx: line 2: syntax error near unexpected token `)' 
$aKsj2sdk1.4.2/include/jvmpi.hUT)Ôò>UxPÉÔ.âüÀÄ'V?t@]·? 
 
!!! ERROR: dev-java/sun-jdk-1.4.2 failed. 
!!! Function src_unpack, Line 39, Exitcode 2 
!!! (no error message) 
 
--------------------------- ACCESS VIOLATION SUMMARY --------------------------- 
LOG FILE = "/tmp/sandbox-sun-jdk-1.4.2-21048.log" 
 
open_wr:   /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin 
-------------------------------------------------------------------------------- 
 
 
The usage of "tail +507" in this ebuild is not POSIX conform and fails with current 
coreutils (5.0-r1). I suggest fixing it to "tail -n 507". The -n option works also with 
older tail versions. This will fix the sandbox violation. 
 
Note that this affects all sun-jdk versions.
Comment 2 Tom Fredrik Blenning Klaussen 2003-08-23 14:42:56 UTC
It might be that 'tail +507' is not POSIX conform. But 'tail +507 foo' means something different than 'tail -n 507 foo'.

Explanation follows:

'tail +507 foo' means: take the tail of the file "foo", skipping the first 507 lines.

'tail -n 507 foo' means: take the the last 507 lines of file "foo".

So unless you have a conforming way of doing things, which also does what it's suppose to. We better stick with what works ;)
Comment 3 Andreas Simon 2003-08-23 15:44:06 UTC
You can't stick with tail +507 because it doesn't work. 
 
But how about 'tail -n +507'? I forgot the '+' in my last comment ;-) 
tail -n +507 was tested by me and works. 
Comment 4 Adrian Almenar 2003-08-23 18:58:50 UTC
I need more information to check this, like the output of emerge info, which 
is the output of qpkg -f /bin/tail ?? 
 
Also, i would like to point that this ebuild has been tested a lot, we've been 
using tail +xxx since JDK version 1.3. 
Comment 5 Andreas Simon 2003-08-24 00:38:28 UTC
Okay, here the requested information:

# emerge --info
Portage 2.0.49 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r3, 2.6.0-test3-mm2)
=================================================================
System uname: 2.6.0-test3-mm2 i686 AMD Athlon(tm) XP 1800+
ccache version 2.2 [enabled]
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-xp -O2 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox fixpackages"
GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/opt/portage /opt/portage-gnome"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="x86 oss apm avi encode foomaticdb libg++ mikmod mpeg ncurses nls pdflib quicktime spell xmms xv gdbm berkdb slang readline arts tetex tcltk java sdl gpm libwww perl python imlib qt kde motif cdr 3dnow alsa crypt cups dvd gif -gnome gtk gtk2 imap ipv6 jpeg lcms mad maildir mmx mozilla mule oggvorbis opengl pam png sasl sse ssl -svga tcpd threads tiff truetype X xml2 zlib esd"


# qpkg -f -v /bin/tail
sys-apps/coreutils-5.0-r1 *


# /usr/bin/tail --version
tail (coreutils) 5.0
Written by Paul Rubin, David MacKenzie, Ian Lance Taylor, and Jim Meyering.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


# /usr/bin/tail +507 /dev/null
/usr/bin/tail: +507: No such file or directory
==> /dev/null <==


As you can see with the version of tail from the coreutils, the '-n' is required and cannot be omitted like with older tail versions. Without '-n' tails interprets +507 as a file name.

The 'tail +xxx' which is used since JDK version 1.3 worked fine until Gentoo switched to coreutils, which was recently.
Comment 6 Andreas Simon 2003-08-29 01:53:12 UTC
This bug is a special case of bug #23116 which is about the general head/tail 
problem with the coreutils. Maybe it should be taged as a duplicate, I am not 
sure. 
Comment 7 Andreas Simon 2003-08-31 04:48:02 UTC
Just for the records, the new sun-jdk-1.4.2.01.ebuild is broken too, and thus cannot be installed.

My proposed fix for this one:
- tail +${startAt} ${DISTDIR}/${At} > install.sfx
+ tail -n +${startAt} ${DISTDIR}/${At} > install.sfx
Comment 8 Adrian Almenar 2003-09-09 21:54:58 UTC
I will close it as WORKSFORME since i have: 
 
sirius# /usr/bin/tail --version 
tail (coreutils) 5.0 
 
sirius # qpkg -f -v /bin/tail 
sys-apps/coreutils-5.0-r1 * 
 
Tested with FEATURES="sandbox" and FEATURES="-sandbox" 
 
Also your error shows:  
ACCESS DENIED  open_wr:   /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin  
./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2-linux-i586.bin: 
Permission 
 
You have the correct permissions on that file ? 
 
Reopen if it still happens 
 
Comment 9 Andreas Simon 2003-09-10 00:37:14 UTC
If the error cause would be a permission problem my fix woudn't work, would it?
No, permissions have nothing to do with it. It's the tail call in the ebuild which errors out and which causes the java-installer to be unexecutable.

I updated coreutils in the meantime to coreutils-5.0-r2 and after that to coreutils-5.0-r3 and still have the error.

# emerge sun-jdk
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-java/sun-jdk-1.4.2.01 to /
>>> md5 src_uri ;-) j2sdk-1_4_2_01-linux-i586.bin
>>> Unpacking source...
tail: +473: No such file or directory
ACCESS DENIED  open_wr:   /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin
./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin: Permission denied
Comment 10 Andreas Simon 2003-09-10 00:37:14 UTC
If the error cause would be a permission problem my fix woudn't work, would it?
No, permissions have nothing to do with it. It's the tail call in the ebuild which errors out and which causes the java-installer to be unexecutable.

I updated coreutils in the meantime to coreutils-5.0-r2 and after that to coreutils-5.0-r3 and still have the error.

# emerge sun-jdk
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-java/sun-jdk-1.4.2.01 to /
>>> md5 src_uri ;-) j2sdk-1_4_2_01-linux-i586.bin
>>> Unpacking source...
tail: +473: No such file or directory
ACCESS DENIED  open_wr:   /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin
./install.sfx: line 1: /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin: Permission denied
íA-sj2sdk1.4.2_01/include/UT B?UxP: No such file or directory
./install.sfx: line 2: r/IzÄ: No such file or directory
íAäNsj2sdk1.4.2_01/include/linux/UT B?UxP: No such file or directory
$3Osj2sdk1.4.2_01/include/linux/jni_md.hUTØB?UxP: No such file or directory
: No such file or directory
$§Psj2sdk1.4.2_01/include/linux/jawt_md.hUTØB?UxP: No such file or directory
$nsj2sdk1.4.2_01/include/jvmpi.hUTØB?UxP: No such file or directory
$Ssj2sdk1.4.2_01/include/jvmdi.hUTØB?UxP: No such file or directory
./install.sfx: line 3: r/âüÀÄ: No such file or directory
$&#9618;j2sdk1.4.2_01/README.htmlUTØB?UxP'near unexpected token `{?
$ssj2sdk1.4.2_01/src.zipUTÔB?UxP&r/ù0¥ÌO/I:P~-Ó¯
$&#9618;j2sdk1.4.2_01/README.htmlUTØB?UxP&r/Ö&kÄ_
$O&#9618;j2sdk1.4.2_01/THIRDPARTYLICENSEREADME.txtUTØB?UxPK'

!!! ERROR: dev-java/sun-jdk-1.4.2.01 failed.
!!! Function src_unpack, Line 50, Exitcode 2
!!! (no error message)

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-sun-jdk-1.4.2.01-20725.log"

open_wr:   /usr/portage/distfiles/j2sdk-1_4_2_01-linux-i586.bin
--------------------------------------------------------------------------------


I wonder why it works for you. Maybe it has something to do with gcc-3.3.1 (I use currently gcc-3.3.1-r1). In gcc's Changelog I see that they have now a coreutils patch included to fix "broken tail calls". But even recompiling coreutils with this patched gcc did'nt change anything for me. But I am not sure if this has to do anything with this issue at all. I mean patching gcc to fix broken tail calls? Common! I would fix the broken calls...

But anyway, as nobody is able to confirm this error, ignore it. I won't reopen it unless I find at least one more person who expierience the same.

Thanks for your time.
Comment 11 Andreas Simon 2003-09-10 00:45:37 UTC
Just a small remark: In dev-lang/ocaml George Shapovalov just fixed a similar broken tail call (although it did'nt break for him):

*ocaml-3.06-r2 (09 Sep 2003)

  09 Sep 2003; George Shapovalov <george@gentoo.org> ocaml-3.06-r2.ebuild, metadata.xml :
  ocaml was using uotdated "head -1" construct throughout. Changed this to "head -n 1",
  see #27835 for details.


Maybe a Gentoo-wide policy is in order: Is 'tail XXX' outdated or not? Right now it's outdated in some packages and not so in other packages.
;-)