Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 583282 - sys-apps/sandbox: libsandbox.c:check_syscall():989: failure (Value too large for defined data type) due to use of non-LFS interfaces internally
Summary: sys-apps/sandbox: libsandbox.c:check_syscall():989: failure (Value too large ...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Sandbox (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sandbox Maintainers
URL:
Whiteboard:
Keywords:
: 544570 584930 598218 598224 605358 681892 784509 (view as bug list)
Depends on:
Blocks: lfs-tracker
  Show dependency tree
 
Reported: 2016-05-17 11:16 UTC by Louis Sautier (sbraz)
Modified: 2022-12-30 20:43 UTC (History)
12 users (show)

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


Attachments
gcc-build-logs.tar.bz2 (gcc-build-logs.tar.bz2,235.49 KB, application/x-bzip2)
2016-05-17 11:16 UTC, Louis Sautier (sbraz)
Details
emerge-info.txt (emerge-info.txt,14.12 KB, text/plain)
2016-05-17 11:18 UTC, Louis Sautier (sbraz)
Details
sandbox-verboserer.patch (file_583282.txt,427 bytes, patch)
2017-06-28 23:51 UTC, ephemer0l
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Louis Sautier (sbraz) gentoo-dev 2016-05-17 11:16:45 UTC
Created attachment 434518 [details]
gcc-build-logs.tar.bz2

I think this might be related to https://bugs.gentoo.org/show_bug.cgi?id=471102
I tried mounting PORTAGE_TMPDIR on a tmpfs and the compilation succeeded.

 * /var/tmp/portage/sys-apps/sandbox-2.10-r2/work/sandbox-2.10/libsandbox/libsandbox.c:check_syscall():989: failure (Value too large for defined data type):
 * ISE:
        abs_path: (null)
        res_path: /var/tmp/portage/sys-devel/gcc-5.3.0/work/build/x86_64-pc-linux-gnu/32/libgomp/conftest.val
Comment 1 Louis Sautier (sbraz) gentoo-dev 2016-05-17 11:18:47 UTC
Created attachment 434520 [details]
emerge-info.txt
Comment 2 SpanKY gentoo-dev 2016-06-03 18:46:25 UTC
*** Bug 584930 has been marked as a duplicate of this bug. ***
Comment 3 SpanKY gentoo-dev 2016-11-10 21:44:44 UTC
*** Bug 598224 has been marked as a duplicate of this bug. ***
Comment 4 SpanKY gentoo-dev 2016-11-10 21:50:48 UTC
*** Bug 598218 has been marked as a duplicate of this bug. ***
Comment 5 ephemer0l 2017-06-28 14:36:58 UTC
I am seeing the same behavior on an XFS filesystem with 256b inodes.
Comment 6 ephemer0l 2017-06-28 23:51:28 UTC
Created attachment 478316 [details, diff]
sandbox-verboserer.patch

Applying this patch slyfox on IRC gave me when compiling on XFS with inodes at 256 the build fails with a bit more verbose "ERRNO: 75". When compiling in a RAM disk the issue isn't present.
Comment 7 Sergei Trofimovich (RETIRED) gentoo-dev 2019-12-26 11:45:08 UTC
I think the issue here is intentional non-LFS interface use. If it would be unintentional we would just fix gcc. But gcc needs to probe all available interfaces.

If the call is a proxy of user's call sandbox ought to pass through the error back to user instead of crashing itself.

If the call is sandbox's own internal function (like, stat() to check things) it should use LFS form of a call.

We'll need to figure which of two is this case.
Comment 8 Bruno 2020-12-19 21:06:12 UTC
Any progress on this?

I'm building 32bit packages for an older system in a chroot on a more recent system running 64bit kernel where I move the build-chroot from smallish XFS to large XFS partition. On the large partition XFS uses 64bit inodes.
Since the move sandbox fails on all (found none wihich worked) packages during install phase.
Note that with recent kernels tmpfs can also be configured to use 64bit inodes!


It seems to be mostly libsandbox checking stat() calls that fail.
But interestingly the output looks weird:
make[3]: Entering directory '/var/tmp/portage/sys-apps/findutils-4.7.0/work/findutils-4.7.0/doc'
make[3]: Nothing to be done for 'install-exec-am'.
 /bin/mkdir -p '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info'
 * ACCESS DENIED:  mkdir:        /var
 /usr/lib/portage/python3.7/ebuild-helpers/xattr/install -c -m 644 ./find.info ./find.info-1 ./find.info-2 ./find-maint.info '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info'
 install-info --info-dir='/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info' '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info/find.info'
 install-info --info-dir='/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info' '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info/find-maint.info'



 * --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
 * LOG FILE: "/var/tmp/portage/sys-apps/findutils-4.7.0/temp/sandbox.log"
 * 
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: mkdir
S: deny
P: /var
A: /var
R: /var
C: mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image 

F: mkdir
S: deny
P: /var
A: /var
R: /var
C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/bin 

F: mkdir
S: deny
P: /var
A: /var
R: /var
C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/man/man1 

F: mkdir
S: deny
P: /var
A: /var
R: /var
C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/bin 
                     ^
F: mkdir
S: deny
P: /var
A: /var
R: /var
C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/man/man1 
                     ^
F: mkdir
S: deny
P: /var
A: /var
R: /var
C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info 
                     ^


In the output /var/tmp/... is interestingly written with a space instead of slash after var.
Comment 9 Ionen Wolkens gentoo-dev 2021-04-22 11:14:27 UTC
*** Bug 784509 has been marked as a duplicate of this bug. ***
Comment 10 Sergei Trofimovich (RETIRED) gentoo-dev 2021-04-22 13:58:46 UTC
(In reply to Bruno from comment #8)
> Any progress on this?
> 
> I'm building 32bit packages for an older system in a chroot on a more recent
> system running 64bit kernel where I move the build-chroot from smallish XFS
> to large XFS partition. On the large partition XFS uses 64bit inodes.
> Since the move sandbox fails on all (found none wihich worked) packages
> during install phase.
> Note that with recent kernels tmpfs can also be configured to use 64bit
> inodes!
> 
> 
> It seems to be mostly libsandbox checking stat() calls that fail.
> But interestingly the output looks weird:
> make[3]: Entering directory
> '/var/tmp/portage/sys-apps/findutils-4.7.0/work/findutils-4.7.0/doc'
> make[3]: Nothing to be done for 'install-exec-am'.
>  /bin/mkdir -p
> '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info'
>  * ACCESS DENIED:  mkdir:        /var
>  /usr/lib/portage/python3.7/ebuild-helpers/xattr/install -c -m 644
> ./find.info ./find.info-1 ./find.info-2 ./find-maint.info
> '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info'
>  install-info
> --info-dir='/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info'
> '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info/find.info'
>  install-info
> --info-dir='/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info'
> '/var/tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info/find-maint.
> info'
> 
> 
> 
>  * --------------------------- ACCESS VIOLATION SUMMARY
> ---------------------------
>  * LOG FILE: "/var/tmp/portage/sys-apps/findutils-4.7.0/temp/sandbox.log"
>  * 
> VERSION 1.0
> FORMAT: F - Function called
> FORMAT: S - Access Status
> FORMAT: P - Path as passed to function
> FORMAT: A - Absolute Path (not canonical)
> FORMAT: R - Canonical Path
> FORMAT: C - Command Line
> 
> F: mkdir
> S: deny
> P: /var
> A: /var
> R: /var
> C: mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image 
> 
> F: mkdir
> S: deny
> P: /var
> A: /var
> R: /var
> C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/bin 
> 
> F: mkdir
> S: deny
> P: /var
> A: /var
> R: /var
> C: /bin/mkdir -p /var
> tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/man/man1 
> 
> F: mkdir
> S: deny
> P: /var
> A: /var
> R: /var
> C: /bin/mkdir -p /var tmp/portage/sys-apps/findutils-4.7.0/image/usr/bin 
>                      ^
> F: mkdir
> S: deny
> P: /var
> A: /var
> R: /var
> C: /bin/mkdir -p /var
> tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/man/man1 
>                      ^
> F: mkdir
> S: deny
> P: /var
> A: /var
> R: /var
> C: /bin/mkdir -p /var
> tmp/portage/sys-apps/findutils-4.7.0/image/usr/share/info 
>                      ^
> 
> 
> In the output /var/tmp/... is interestingly written with a space instead of
> slash after var.

This does not look like an LFS problem. Please attach full build.log.
Comment 11 SpanKY gentoo-dev 2021-10-21 05:42:30 UTC
*** Bug 605358 has been marked as a duplicate of this bug. ***
Comment 12 SpanKY gentoo-dev 2021-10-22 04:30:21 UTC
*** Bug 544570 has been marked as a duplicate of this bug. ***
Comment 13 SpanKY gentoo-dev 2021-10-22 04:44:23 UTC
*** Bug 681892 has been marked as a duplicate of this bug. ***
Comment 14 Larry the Git Cow gentoo-dev 2021-11-05 10:25:00 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=382f70b8d93d012648edc7a42087a6d4d5a103eb

commit 382f70b8d93d012648edc7a42087a6d4d5a103eb
Author:     Mike Frysinger <vapier@gentoo.org>
AuthorDate: 2021-11-05 10:23:34 +0000
Commit:     Mike Frysinger <vapier@gentoo.org>
CommitDate: 2021-11-05 10:23:34 +0000

    libsandbox/libsbutil: use faccessat for file-existence tests
    
    This is faster than using stat since it doesn't have to gather all
    the metadata, and should avoid LFS issues as a result.
    
    Bug: https://bugs.gentoo.org/583282
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>

 libsandbox/pre_check_openat.c              | 15 +++------------
 libsandbox/wrapper-funcs/fopen_pre_check.c |  3 +--
 libsbutil/src/file.c                       | 14 +-------------
 3 files changed, 5 insertions(+), 27 deletions(-)
Comment 15 Larry the Git Cow gentoo-dev 2021-11-06 03:51:40 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=35459036a204bbf147b11631317aff9eb1804573

commit 35459036a204bbf147b11631317aff9eb1804573
Author:     Mike Frysinger <vapier@gentoo.org>
AuthorDate: 2021-11-06 03:38:02 +0000
Commit:     Mike Frysinger <vapier@gentoo.org>
CommitDate: 2021-11-06 03:38:02 +0000

    libsandbox: reduce & inline the __64_{pre,post}.h headers
    
    Now that we use 64-bit stat & lstat explicitly everywhere, we don't
    need these dynamic redirects for 64-bit wrappers.  The off_t define
    is only used by one file anymore too, but we can inline that.
    
    That leaves the SB64 define which we use inconsistently in places.
    In some 64-bit modules that include the 32-bit, we use SB64 to switch
    between the 64-bit & 32-bit APIs.  In other places, the 64-bit file
    is responsible for redefining the few relevant APIs.  Let's switch
    all the files away from SB64 and to defining the single thing that
    the 64-bit module needs directly.  It's either the same or fewer LOC
    this way, and doesn't seem any more or less difficult to maintain.
    The __64_{pre,post}.h & SB64 define weren't easily discoverable.
    
    Bug: https://bugs.gentoo.org/583282
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>

 libsandbox/pre_check_openat64.c              | 2 --
 libsandbox/wrapper-funcs/__64_post.h         | 4 ----
 libsandbox/wrapper-funcs/__64_pre.h          | 4 ----
 libsandbox/wrapper-funcs/__open64_2.c        | 4 ++--
 libsandbox/wrapper-funcs/__openat64_2.c      | 4 ++--
 libsandbox/wrapper-funcs/__openat_2.c        | 6 +-----
 libsandbox/wrapper-funcs/fopen.c             | 7 +------
 libsandbox/wrapper-funcs/fopen64.c           | 4 ++--
 libsandbox/wrapper-funcs/fopen64_pre_check.c | 2 --
 libsandbox/wrapper-funcs/open64.c            | 4 ++--
 libsandbox/wrapper-funcs/openat.c            | 6 +-----
 libsandbox/wrapper-funcs/openat64.c          | 4 ++--
 libsandbox/wrapper-funcs/truncate.c          | 4 +++-
 libsandbox/wrapper-funcs/truncate64.c        | 3 +--
 14 files changed, 17 insertions(+), 41 deletions(-)

https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=632cc66ba52eb6aa7fd3e457c64d9186389a20b4

commit 632cc66ba52eb6aa7fd3e457c64d9186389a20b4
Author:     Mike Frysinger <vapier@gentoo.org>
AuthorDate: 2021-11-06 03:14:42 +0000
Commit:     Mike Frysinger <vapier@gentoo.org>
CommitDate: 2021-11-06 03:14:42 +0000

    change FS calls to use 64-bit interfaces explicitly
    
    Make sure we use 64-bit FS interfaces when accessing the FS.  This
    is needed not only to stat or open large files, but even files with
    64-bit inodes.
    
    Bug: https://bugs.gentoo.org/583282
    Signed-off-by: Mike Frysinger <vapier@gentoo.org>

 configure.ac                              |  7 +++++++
 libsandbox/canonicalize.c                 |  8 ++++----
 libsandbox/libsandbox.c                   | 14 +++++++-------
 libsandbox/pre_check_mkdirat.c            |  6 +++---
 libsandbox/trace.c                        |  2 +-
 libsandbox/wrapper-funcs/__wrapper_exec.c |  4 ++--
 libsbutil/include/rcscripts/util/file.h   |  2 +-
 libsbutil/sb_close.c                      |  4 ++--
 libsbutil/src/file.c                      | 24 ++++++++++++------------
 src/namespaces.c                          |  4 ++--
 tests/get-group.c                         |  4 ++--
 tests/get-user.c                          |  4 ++--
 tests/test-skel-0.c                       |  2 +-
 tests/trace-memory_static_tst.c           |  4 ++--
 14 files changed, 48 insertions(+), 41 deletions(-)
Comment 16 SpanKY gentoo-dev 2021-11-06 03:52:24 UTC
should be fixed for sandbox-3.2+

if it still fails, best to file a new bug at that point with updated logs