Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 21766 - coreutils-5.0 breaks sandbox
Summary: coreutils-5.0 breaks sandbox
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Nicholas Jones (RETIRED)
URL:
Whiteboard:
Keywords:
: 24951 25484 25702 26037 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-27 09:21 UTC by Spider (RETIRED)
Modified: 2014-03-11 06:22 UTC (History)
16 users (show)

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


Attachments
test.c (test.c,2.34 KB, text/plain)
2003-05-27 16:20 UTC, Alastair Tse (RETIRED)
Details
sandbox-PATH_MAX-fix.patch (sandbox-PATH_MAX-fix.patch,12.22 KB, patch)
2003-06-22 12:43 UTC, Martin Schlemmer (RETIRED)
Details | Diff
sandbox-getcwd-fix.patch (sandbox-getcwd-fix.patch,59.25 KB, patch)
2003-07-27 05:29 UTC, Martin Schlemmer (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Spider (RETIRED) gentoo-dev 2003-05-27 09:21:30 UTC
coreutils  has an "unlink" for /confdir3  Which breaks sandbox on my system.


Reproducible: Always
Steps to Reproduce:
Comment 1 Alastair Tse (RETIRED) gentoo-dev 2003-05-27 09:29:48 UTC
i can reproduce this too. 

there is something with glibc that truncates the first terms of of ${PORTAGE_TMPDIR} out of the path name. i don't know what a clean fix is, or whether that is a bug with either glibc or the configure script.
Comment 2 Seemant Kulleen (RETIRED) gentoo-dev 2003-05-27 15:49:06 UTC
can someone paste or give an analysis so we can send a bug report upstream?

alastair?
Comment 3 Alastair Tse (RETIRED) gentoo-dev 2003-05-27 16:19:28 UTC
well, it looks more like a sandbox problem now. attached is the offending code, to reproduce:

gcc -o testdir test.c
SANDBOX_WRITE=/var/tmp/portage:/dev /usr/lib/portage/bin/sandbox ./testdir

i think maybe unlink is the one that can't accept a larger pathname than PATH_MAX

btw, for reference, it dies on the line:

checking whether getcwd properly handles paths longer than PATH_MAX... checking whether getcwd is declared... yes

Comment 4 Alastair Tse (RETIRED) gentoo-dev 2003-05-27 16:20:28 UTC
Created attachment 12472 [details]
test.c

test case that breaks sandbox
Comment 5 Seemant Kulleen (RETIRED) gentoo-dev 2003-05-27 16:27:06 UTC
Az, looks like a sandbox issue
Comment 6 J Robert Ray 2003-05-29 03:09:21 UTC
sandbox relies heavily on getcwd to function.  This configure script is testing if getcwd works for huge paths by create a huge path and running getcwd on it...

checking whether getcwd properly handles paths longer than PATH_MAX... checking whether getcwd is declared... yes
no

getcwd DOES NOT properly handle paths longer than PATH_MAX on my system.  It's returning '/jrray/tmp/sandbox/confdir3/confdir3/confdir3/conf...' instead of '/home/jrray/tmp/sandbox/confdir3/confdir3/confdir3/conf...'

You can see this for yourself if you patch the test.c to look like:

      if ((len = strlen (c)) != cwd_len)
	{
+	  fprintf(stderr, "length mismatch\n'%s'\n", c);
	  fail = 1;
	  break;
	}


Without a working getcwd, it is impossible to make sandbox survive this test.  But if getcwd worked, this test would be irrelevent.

Looks to me that this package will need to disable sandbox.

- Robert
Comment 7 bartron 2003-05-31 18:18:43 UTC
I ran into a similar problem when experimenting with long paths a while ago. Turned out this is a limitation of the `getcwd' syscall, which allocates a single page, puts the current directory name at the end of it, then walks up the tree until either it reaches the root, or the current directory name doesn't fit into the remaining 
space; then copies the result to userspace. So no matter how big the passed in buffer is, the limit is the platform's page size (4K on x86). 
Using "/proc/self/pwd", which internally depends on getcwd, won't work either. Didn't look into 2.5.x kernels yet, but here are my test functions:

---

#include <sys/syscall.h>
char *getcwd_s(char *buf, size_t size)
{
  long rv = syscall(SYS_getcwd, buf, size);
  if(rv < 0) 
    return (errno = -rv, NULL);
  return buf;
}

char *getcwd_p(char *buf, size_t size)
{
  /* readlink does not append '\0' */
  memset(buf, 0, size);
  if(readlink("/proc/self/cwd", buf, size-1) < 0)
    return NULL;
  return buf;
}
/* #define getcwd getcwd_s  /*-*/
/* #define getcwd getcwd_p  /*-*/

---

  One solution would be to add glibc's generic getcwd (in sysdeps/posix) to sandbox. The version I was using back then (glibc-2.1) had a minor bug in it though (when a certain depth was reached and it had to enlarge `dotlist', it didn't put a '/' between the old and the new part) which always made it abort with ENOENT at depth 76.
With that fixed, however, it works for any length/depth paths (although a lot slower than the syscall).

  Another problem is with the test program itself; the result buffer is declared as `char buf[PATH_MAX+20]' (PATH_MAX is 4096 and gets pulled in from <linux/limits.h>), but the call is made as `getcwd(buf, PATH_MAX)', which would fail with longer paths even if getcwd() could handle them.
Changing the second call to `getcwd(buf, PATH_MAX+19)', the 
test succeeded for me with the generic getcwd().
Comment 8 Martin Schlemmer (RETIRED) gentoo-dev 2003-06-22 12:43:51 UTC
Created attachment 13694 [details, diff]
sandbox-PATH_MAX-fix.patch

  22 Jun 2003; Martin Schlemmer <azarah@gentoo.org> libsandbox.c,
canonicalize.c
  create-localdecls :
  When checking path names of files accessed, we need to canonicalize it, else
  it may be a symlink in a 'write allowed' directory pointing to a file in a
  directory we should not have write access to.

  With something like coreutils-5.0, we have two problems:
  1)  One of the tests checks if getcwd() can return a path longer than
      PATH_MAX.  This test then tries to create a dir which even while
      created local (mkdir("conftest2")), it ends up being resolved with
      a name that is much larger than PATH_MAX.  The problem now is that
      canonicalize() have undefined behaviour when the path was too long
      (returned wrongly truncated paths, etc), and pass the wrong path to
      before_syscall() (causing the bogus sandbox violations).
  2)  The ecanonicalize() function we used, along with the canonicalize()
      function did not support longer than PATH_MAX.  This is partly a
      cause for 1), but the error checking (rather lack of it) of calls
      to erealpath() in canonicalize() was the prime reason for 1).

  As we do not use this canonicalized name to call the function, we resolve
this
  by fixing canonicalize() to do better error checking, and ecanonicalize() as
  well as all functions in libsandbox.c to use a PATH_MAX of 'PATH_MAX * 2'.
  While they will resolve paths properly now, and can check if a write/read is
  allowed, the functions called from the sandboxed environment will still work
  as expected.

  This should resolve bug #21766.
Comment 9 Martin Schlemmer (RETIRED) gentoo-dev 2003-06-22 13:01:58 UTC
Nick, I applied sandbox changes to CVS.  Could we get a new portage out?
Comment 10 Martin Schlemmer (RETIRED) gentoo-dev 2003-06-30 14:58:59 UTC
Will be fixed when portage-2.0.48-r2(3?) is unmasked.

Comment 11 Joe Kallar (RETIRED) gentoo-dev 2003-07-18 15:57:28 UTC
FYI, I received the following:

make[2]: Leaving directory `/var/tmp/portage/coreutils-5.0/work/coreutils-5.0'
make[1]: Leaving directory `/var/tmp/portage/coreutils-5.0/work/coreutils-5.0'
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-coreutils-5.0-13562.log"

unlink:    /confdir3
--------------------------------------------------------------------------------

Today on both a SPARC box running ~sparc, and an x86 running stable. It prevented compilation of coreutils and the rest of emerge world.

ultra60 gentoo # emerge -s portage
Searching...   
[ Results for search key : portage ]
[ Applications found : 3 ]

(snip)

*  sys-apps/portage
      Latest version available: 2.0.48-r1
      Latest version installed: 2.0.48-r1
      Size of downloaded files: 191 kB
      Homepage:    http://www.gentoo.org
      Description: Portage ports system
Comment 12 SpanKY gentoo-dev 2003-07-18 16:00:33 UTC
FYI read comment #10 
Comment 13 Seemant Kulleen (RETIRED) gentoo-dev 2003-07-24 04:08:17 UTC
reopening -- this seems to affect portage -r5 and -r7 as well
Comment 14 Mathias Gumz 2003-07-24 04:12:32 UTC
hey folks, i use portage 2.0.48-r7 now and coreutils still refuse to be emerged (with -r5 too), i told this naz and seemant already and they suggest to paste the errors here, so here we go:

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-coreutils-5.0-17107.log"

unlink:    /portage/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confd

and so on and so on, emerge info is:

Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
=================================================================
System uname: 2.4.20-gentoo-r5 i686 AMD Athlon(tm) processor
GENTOO_MIRRORS="ftp://gentoo.linux.no/pub/gentoo/ http://gentoo.inode.at/ http://ftp.easynet.nl/mirror/gentoo/ ftp://ftp.easynet.nl/mirror/gentoo/ ftp://gentoo.inode.at/source/"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/scratch/portage"
PORTDIR_OVERLAY="/usr/local/portage"
USE="x86 oss 3dnow apm avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gdbm berkdb slang readline arts tetex svga tcltk java guile ruby mysql X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla cdr aalib acpi fbcon imap gtk2"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-O3 -mcpu=athlon-tbird -march=i686 -DHAVE_ERRNO_AS_DEFINE=1 -pipe"
CXXFLAGS="-O3 -mcpu=athlon-tbird -march=i686 -DHAVE_ERRNO_AS_DEFINE=1 -pipe"
ACCEPT_KEYWORDS="x86 ~x86"
MAKEOPTS="-j8"
AUTOCLEAN="yes"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
FEATURES="sandbox ccache distcc"

any suggestions?

regards, mathias
Comment 15 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-25 11:41:57 UTC
I have a fait idea that this goes deeper than I thought.  It works fine
on my dev box, but on my box at work, it does not.  Looking into it ....
Comment 16 Reporter 2003-07-25 20:56:17 UTC
I think the answer is in comment #6 and comment #7...

Even with standard locations, the testprog tries to unlink 
  /tmp/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/....
instead of
  /var/tmp/portage/coreutils-5.0/work/coreutils-5.0/confdir3/confdir3/....

Comment 17 Reporter 2003-07-25 21:05:44 UTC
Just noticed...

If PORTAGE_TMPDIR is not /var/tmp and the access violation occurs, sandbox 
crashes because the buffer that is used to print the violation is way to small 
too hold a path this long!
Comment 18 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-27 01:45:25 UTC
Yes, I fixed the crash.  Anyhow, it works fine with a 2.5/2.6 kernel, but
not with a 2.4 one it seems.  And getting getcwd to work without using a
system call, you need stat (lstat() actually), but for that I still need
a system call, so guess will have to add a hack rather.

Comment 19 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-27 05:29:53 UTC
Created attachment 15076 [details, diff]
sandbox-getcwd-fix.patch

As my systems had 2.5 kernel, the getcwd system call handled strings larger
than PATH_MAX (bug #21766).  It however does not work the same on 2.4 kernels.

To fix, I added the posix implementation of getcwd() (from glibc cvs) that
do not need the system call.  We use the default getcwd() function via a
wrapper (egetcwd), and then lstat the returned path.  If lstat fails, it
means the current directory was removed, OR that the the system call for
getcwd failed (curious is that it do not fail and return NULL or set
errno, but rather just truncate the retured directory - usually from the
start), and if so, we use the generic getcwd() function (__egetcwd).  Note
that we do not use the generic version all the time, as it calls lstat()
a great number of times, and performance degrade much.

Note that the patch do include some formatting changes, so it might be hard
to see the real fix.
Comment 20 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-27 05:31:42 UTC
Anyhow, its commited to CVS, so new version of portage should fix this.
Comment 21 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-27 07:12:20 UTC
Nick, just hang on before you may do a new rev - I need to check in one more
fix.
Comment 22 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-27 08:07:09 UTC
Ok, fixed another small but possible fatal bug - Nick, should be fine now
for new portage.
Comment 23 David Holm (RETIRED) gentoo-dev 2003-07-28 04:36:50 UTC
I get the following sandbox violation (looks very odd):

unlink:    /portage/coreutils-5.0-r1/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3
Comment 24 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-28 04:51:28 UTC
Yes, you will if you do not have the latest CVS sandbox code (Note, not in
any portage yet ... ).
Comment 25 Phil Richards 2003-07-28 05:55:53 UTC
I'm having this problem now (I already have coreutils-5.0 installed;
the failure is in trying to upgrade to 5.0-r1) [portage-2.0.48-r7]

phil
Comment 26 Paul Slinski 2003-07-28 06:44:16 UTC
Ditto, nice error:

unlink:    /portage/coreutils-5.0-r1/work/coreutils-5.0/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3

That's an odd one for sure.
Comment 27 Martin Schlemmer (RETIRED) gentoo-dev 2003-07-28 06:50:57 UTC
Again, it is fixed in sandbox CVS, but is not yet released in a portage version.
For now, do:

  # FEATURES="-sandbox" emerge coreutils


Thanks.
Comment 28 SpanKY gentoo-dev 2003-07-29 17:28:02 UTC
*** Bug 25484 has been marked as a duplicate of this bug. ***
Comment 29 Nicholas Jones (RETIRED) gentoo-dev 2003-07-30 11:17:10 UTC
It's in 2.0.49_pre17
Comment 30 Jim Nutt 2003-07-30 18:25:30 UTC
Hmmm. doing:

FEATURES="-sandbox" emerge coreutils

doesn't seem to work. I still get a sandbox violation for the monster unlink. Any other suggestions?
Comment 31 SpanKY gentoo-dev 2003-08-01 15:15:58 UTC
*** Bug 25702 has been marked as a duplicate of this bug. ***
Comment 32 Martin Schlemmer (RETIRED) gentoo-dev 2003-08-01 15:52:03 UTC
 # FEATURES="-sandbox -usersandbox" emerge coreutils

Btw, latest 2.0.49 have the new sandbox.
Comment 33 Aron Griffis (RETIRED) gentoo-dev 2003-08-01 18:10:24 UTC
I might have fixed this bug today.  I didn't realize bug 25702 was a duplicate of this one.  Anyway, the configure script tests for a glibc bug, then tries to clean up after itself.  Easiest thing to do is short-circuit the cleanup since it's unnecessary (and error-prone as we've found out).

Take a look at files/coreutils-5.0-confdir3.patch if you're interested in the fix.  I suspect it will continue to apply (maybe with some minor massaging) to newer versions of coreutils.

Since you guys have been looking at this for a while, I'll leave this bug open until you decide whether you like or don't like my fix.  You can close it when you like.
Comment 34 Ioannis Aslanidis (RETIRED) gentoo-dev 2003-08-02 00:56:06 UTC
Nice to see it works now. :)
Comment 35 Martin Schlemmer (RETIRED) gentoo-dev 2003-08-02 03:17:51 UTC
I have thought about that fix as well Aron, but it will not fix the main
issue, which is sandbox should not be limited by PATH_MAX, or rather, it
should be able to handle if it have to resolve a path and in doing so, it
should be able to handle PATH_MAX + 20 or PATH_MAX * 2 or whatever.

Can you guys please try the latest sandbox code without the confdir3 patch ?

Thanks.
Comment 36 Martin Schlemmer (RETIRED) gentoo-dev 2003-08-02 03:20:55 UTC
*** Bug 24951 has been marked as a duplicate of this bug. ***
Comment 37 Martin Holzer (RETIRED) gentoo-dev 2003-08-06 06:22:25 UTC
*** Bug 26037 has been marked as a duplicate of this bug. ***
Comment 38 Martin Schlemmer (RETIRED) gentoo-dev 2003-08-25 13:39:09 UTC
Should be fixed with portage-2.0.49+.
Comment 39 Davison Long 2005-03-05 12:29:24 UTC
I'm not sure if I've got something strange going on because of my particular setup (Portage on a Redhat system), but I'm getting this same issue on coreutils-5.2.1-r4

Following is what is what I receive when trying to emerge coreutils:
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-sys-apps_-_coreutils-5.2.1-r4-26688.log"

unlink:    /confdir3
--------------------------------------------------------------------------------

My portage version is:
Portage 2.0.51-r15 (default-linux/x86/2004.2/gcc34, gcc-3.3.5, unavailable, 2.4.20-021stab022.11.777-enterprise i686)
=================================================================
System uname: 2.4.20-021stab022.11.777-enterprise i686 i686
Unknown Host Operating System
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar  1 2005, 03:03:21)]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.9.4, 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.4_p6
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  [Not Present]
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -mcpu=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -mcpu=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 apache2 berkdb bitmap-fonts ccache crypt curl emboss f77 font-server fortran gd gdbm gif imap imlib ipv6 jpeg libg++ libwww mad maildir mysql ncurses nls nptl pam pdflib perl png python readline sasl slang spell ssl svga tcpd tiff truetype-fonts type1-fonts xml2 zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY