Summary: | [powerman overlay] sys-apps/sandbox: incompatible with OS Inferno | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Alex Efros <powerman-asdf> |
Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | jer, mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
strace-emu-segfault.log
strace-emu-ok.log |
Description
Alex Efros
2013-03-26 07:39:17 UTC
The problem with this bug report is that all the ebuilds that fail are in the overlay you maintain. If and when you find an actual sandbox bug, please do report that to the sandbox developers, but I don't see how sys-apps/sandbox is even involved here so the bug's Summary could use some (more) work. (In reply to comment #1) > The problem with this bug report is that all the ebuilds that fail are in > the overlay you maintain. Hmm. I don't understand. Bug isn't in ebuilds, so what's the difference in which overlay they are located? Copy them into /usr/local/portage, if you like to avoid my overlay. > If and when you find an actual sandbox bug, please > do report that to the sandbox developers, but I don't see how > sys-apps/sandbox is even involved here It's involved because FEATURES=-usersandbox fix this issue. Actually you can avoid installing dev-perl/Inferno-RegMgr by simple adding command to run `emu` in, say, /etc/portage/bashrc - so it will be executed inside sandbox when emerging any ebuild. And you can avoid dev-inferno/inferno ebuild by installing OS Inferno manually from sources. This way you completely avoid using my overlay and still will be able to see this issue. I can understand if sandbox developers refuse to fix this bug because they don't wanna support OS Inferno at all (and they are not curious enough to just wonder what's can be wrong between sandbox and inferno), but question where are located these ebuilds are completely irrelevant to this issue. (In reply to comment #2) > (In reply to comment #1) > > The problem with this bug report is that all the ebuilds that fail are in > > the overlay you maintain. > > Hmm. I don't understand. Bug isn't in ebuilds, so what's the difference in > which overlay they are located? Copy them into /usr/local/portage, if you > like to avoid my overlay. You haven't described an actual sandbox bug yet. (In reply to comment #3) > You haven't described an actual sandbox bug yet. That's partially because I can't find any documentation describing what sandbox actually does and how to configure it - so I've no ideas how it limit sandboxed app and thus I can't guess what may be wrong. Here is minimal example (only thing you need is OS Inferno installed): # LD_PRELOAD=libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ emu echo ok Segmentation fault # LD_PRELOAD=libsandbox.so emu echo ok ok I've tried to check sandbox logs (usual and debug), use SANDBOX_VERBOSE=1, SANDBOX_INTRACTV=1 and __SANDBOX_TESTING=yes - no signs of anything wrong in logs. I'm going to attach output of `strace -ff emu echo ok` for both cases, maybe sandbox developers will got an idea what goes wrong. Created attachment 343360 [details]
strace-emu-segfault.log
Created attachment 343362 [details]
strace-emu-ok.log
(In reply to comment #4) the README in the sandbox source code explains things pretty clearly (In reply to comment #7) > the README in the sandbox source code explains things pretty clearly Actually I've looked for docs in sources before whine here about lack of docs. I've read README, but it doesn't explain things I wanna know to be able to guess what may be wrong with inferno: 1) list of all environment variables and their values which let me control sandbox 2) list of all operations intercepted/limited by sandbox, which may help me guess which one may conflict with inferno (btw, after looking at strace log this probably doesn't helps anymore) 3) known bugs/incompatibilities (In reply to comment #8) you said you couldn't find docs on what sandbox does. the README file explains that clearly. there is no real documentation on what vars do what. the only real stable interface is the vars that the PM relies on. otherwise, you can read libsbutil/sbutil.h and the ENV_XXX defines. there is no real list of what functions the sandbox intercepts. "anything that can write/modify the filesystem" is candidate for overloading, and that exact symbol list is determined at configure time by analyzing the C library that sandbox is being compiled against. you can run `readelf -sW /usr/lib64/libsandbox.so` and look at all the exported symbols to see which ones it is actively overriding. setting SANDBOX_VERBOSE=1 gives the best "high level" view into what is happening at runtime. SANDBOX_DEBUG=1 really needs a sandbox compiled with debug code enabled to be useful. __SANDBOX_TESTING won't work on installed libraries (by design). it gets binary patched out during install. stracing doesn't really help because sandbox operates at the C library level -- before syscalls are made. only other documentation is in the TODO file. Not sure is this helps, but here is what I have for now. I've commented all open/creat wrappers in sandbox source, and inferno started ok: # LD_PRELOAD=/var/tmp/portage/sys-apps/sandbox-2.5/work/build-x86/libsandbox/.libs/libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ SANDBOX_VERBOSE=1 SANDBOX_DEBUG=1 emu echo ok ok Next I tried to do something inside inferno (the ";" is inferno shell's prompt): # LD_PRELOAD=/var/tmp/portage/sys-apps/sandbox-2.5/work/build-x86/libsandbox/.libs/libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ SANDBOX_VERBOSE=1 SANDBOX_DEBUG=1 emu ; ls >/dev/null ACCESS ALLOWED opendir: /usr/inferno ; mkdir 1 Segmentation fault Outside of sandbox it works, of course: # emu ; mkdir 1 ; ls -ld 1 d-rwx------ U 4 root root 0 Mar 27 06:18 1 ; rm 1 ; I've tested few more wrappers, these are works: opendir, utime, remove, rmdir, chmod, execvp and these are fail: mkdir, rename, open(according to strace, fail on second call) wrapper-funcs/rename.c contain this line: #define WRAPPER_SAFE() SB_SAFE(oldpath) && SB_SAFE(newpath) and doesn't work. If I change it this way: #define WRAPPER_SAFE() SB_SAFE(newpath) it still doesn't work. But this way: #define WRAPPER_SAFE() SB_SAFE(oldpath) it stop crashing emu and works! See: # LD_PRELOAD=/var/tmp/portage/sys-apps/sandbox-2.5/work/build-x86/libsandbox/.libs/libsandbox.so SANDBOX_ACTIVE=armedandready SANDBOX_ON=1 SANDBOX_READ=/ SANDBOX_VERBOSE=1 SANDBOX_DEBUG=1 SANDBOX_WRITE=/ emu ; mv 1 2 ACCESS ALLOWED rename: /usr/inferno/1 ; mv 2 1 ACCESS ALLOWED rename: /usr/inferno/2 ; (In reply to comment #10) you might be hitting bug 404013. there are two patches referenced in there you might want to try against sandbox-2.6-r1. (In reply to comment #12) > you might be hitting bug 404013. there are two patches referenced in there > you might want to try against sandbox-2.6-r1. I've already tried 2.6-r1, no difference. I've traced code line which result in segfault. It's in libsandbox.c, when function resolve_path() called with follow_link=1, at lines: if (!ret) { char tmp_str1[SB_PATH_MAX]; snprintf(tmp_str1, SB_PATH_MAX, "%s", path); It crash on snprintf() call, but I see nothing wrong with it. The path variable is correct string, I've checked this. Moreover, if I add at very beginning of this function something like this: char __tmp_str1[SB_PATH_MAX]; snprintf(__tmp_str1, SB_PATH_MAX, "%s", path); it won't crash anymore. This added code is NO-OP, so probably something is wrong with memory layout (which is change because of added var and code). Actually I've seen similar symptoms some time ago in few other applications, but don't remember what's was the problem and how to fix it. Here is how it looks (I've added debug sb_printf()). ; mv 1 2 ENTER before_syscall(-100, 21, 0xe7a30ba0, 0x0fe95fe0 '/usr/inferno/1', 0) ENTER resolve_path(0xe79f6004 '/', 0) ENTER resolve_path(0xe7541004 '/', 0) before_syscall: call check_syscall() ENTER check_syscall(0xe7a34160, 21, 0xe7a30ba0, 0x0fe95fe0, 0) ENTER resolve_path(0x0fe95fe0 '/usr/inferno/1', 0) check_syscall: absolute_path='/usr/inferno/1' ENTER resolve_path(0x0fe95fe0 '/usr/inferno/1', 1) check_syscall: resolved_path='/usr/inferno/1' ACCESS ALLOWED rename: /usr/inferno/1 before_syscall: returned from check_syscall() ENTER before_syscall(-100, 21, 0xe7a30ba0, 0x0fe9cde0 '/usr/inferno/2', 0) before_syscall: call check_syscall() ENTER check_syscall(0xe7a34160, 21, 0xe7a30ba0, 0x0fe9cde0, 0) ENTER resolve_path(0x0fe9cde0 '/usr/inferno/2', 0) check_syscall: absolute_path='/usr/inferno/2' ENTER resolve_path(0x0fe9cde0 '/usr/inferno/2', 1) resolve_path: call snprintf(0xe7a1436c, 8192, 0x0fe9cde0) Segmentation fault Instead of segfault it should print: resolve_path: returned from snprintf() (In reply to comment #13) i think you misread my comment. i didn't say "try 2.6-r1", i said "try 2.6-r1 with the two patches from that bug". (In reply to comment #15) > i think you misread my comment. i didn't say "try 2.6-r1", i said "try > 2.6-r1 with the two patches from that bug". They doesn't apply (I tried `ebuild ...-2.6-r1.ebuild prepare` and then manually `patch --dry-run -p1` inside /var/tmp/portage). First patch looks like already (partially?) applied, second fail at last section AFAIR. Alex, if you're still interested in this, could you try the current version? There were some segv fixes over the years, so the problem may be gone now. (In reply to Michał Górny from comment #17) > Alex, if you're still interested in this, could you try the current version? > There were some segv fixes over the years, so the problem may be gone now. No. I don't have this ebuild in overlay any more because I don't install Perl modules using portage for years. I think this issue can be closed now. |