fix event.c for seccomp and ptrace

[jorge-lip]

No description provided.

[jopasserat]

Hey @jorge-lip thanks for the contribution!
However I'm afraid it doesn't work...

I've built and tested your branch against a basic ls

proot -v 3 ls

And I get the exact same output as with your branch, whereas I should see the log message from the seccomp mode activation:

proot info: ptrace acceleration (seccomp mode 2) enabled

You can go and try for yourself with the two static builds that I made available with and without seccomp enabled: https://github.com/proot-me/proot-static-build/releases/tag/v5.1.1

[jopasserat]

Just to be clear, your solution is one of the walls @romainreuillon I and hit while trying to solve the issue: it seems to me that your fix basically disables the seccomp mode for the rest of the execution.

[jorge-lip]

Hi, I'm surprised, it does not work in my fedora25 while the version compiled by me that you can download in the link does work properly  in Fedora 25. I find strange that the static tarball that you release when I untar the proot source code my patch is not inside in tracee/event.c, should it be there applied to the source ? Please check this proot version https://owncloud.indigo-datacloud.eu/index.php/s/GMGedfSrr9xqwDA Cheers, Jorge

…

On Tue, 2017-02-14 at 09:21 -0800, jopasserat wrote: Just to be clear, your solution is one of the walls @romainreuillon I and hit while trying to solve the issue: it seems to me that your fix basically disables the seccomp mode for the rest of the execution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jorge-lip]

Hi Jo, See last line, seccomp is enabled, furthermore I tried with a small  tests doing a loop on read() and the read() calls do not appear in the logs while with PROOT_NO_SECCOMP=1 the read() calls are traced and do appear in the logs. Can you please clone the repo and replace tracee/event.c with the one I shared in owncloud and check it please ? Thanks and sorry, Jorge [jorge@pcjorge udocker]$ ~/.udocker/bin/proot-x86_64-4_8_0 -v 10  -w / -b /home/jorge/mysoft/indigo/udocker/PROOT/r:/tmp/r -r /home/jorge/.udocker/containers/15914148-0fcc-3833-8031- b02875cb1a8d/ROOT /bin/bash proot info: binding = /home/jorge/mysoft/indigo/udocker/PROOT/r:/tmp/r proot info: binding = /home/jorge/.udocker/containers/15914148-0fcc- 3833-8031-b02875cb1a8d/ROOT:/ proot info: pid 24114: translate("/" + "/bin/bash") proot info: pid 24114:          -> "/home/jorge/.udocker/containers/15914148-0fcc-3833-8031- b02875cb1a8d/ROOT/bin/bash" proot info: pid 24114: translate("/" + "/bin/bash") proot info: pid 24114:          -> "/home/jorge/.udocker/containers/15914148-0fcc-3833-8031- b02875cb1a8d/ROOT/bin/bash" proot info: glue rootfs = /tmp/proot-24114-ju3Kg1 proot info: exe = /bin/bash proot info: argv = /bin/bash proot info: initial cwd = / proot info: verbose level = 10 proot info: pid 24114: access to "/dev/pts/5" (fd 0) won't be translated until closed proot info: pid 24114: access to "/dev/pts/5" (fd 1) won't be translated until closed proot info: pid 24114: access to "/dev/pts/5" (fd 2) won't be translated until closed proot info: pid 24114: access to "/proc/24114/fd" (fd 3) won't be translated until closed proot info: ptrace acceleration (seccomp mode 2) enabled

…

On Tue, 2017-02-14 at 09:21 -0800, jopasserat wrote: Just to be clear, your solution is one of the walls @romainreuillon I and hit while trying to solve the issue: it seems to me that your fix basically disables the seccomp mode for the rest of the execution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[alkino]

Thanks for the patch @jorge-lip

It seems me really weird that you fall-through from SIGTRAP to SECCOMP in the switch.

[jopasserat]

@jorge-lip yes the static build is a bit rough as of now: you've got to place a tarball of your source tree under the packages directory. I'll have another look as I can indeed see the seccomp mode enabled with the binary from your owncloud

[jopasserat]

I messed up my static build, I now confirm that it works on my system too. Will evaluate the performance on a real-world application that was facing a huge overhead in the PROOT_NO_SECCOMP mode.

[twhitehead]

Not sure about any performance issues, but this seems to be the only branch I've found that works in an lxc container with seccomp enabled under Fedora 23 running kernel 4.8.14.

[vincenthage]

Hi,

Can you update this PR (either with a small dummy commit, or by closing/opening it) so that the Travis CI can run the tests and verify that everything checks out?

Thanks

[vincenthage]

All tests pass, PR is ready to merge.

[vincenthage]

Though to be sure, can we get a check from everyone that this PR effectively fixes the SECCOMP issue please? It should at least be checked on old (2.6.32) and recent kernels (4.8, 4.9, 4.11).

[vincenthage]

It looks like the Travis tests return a false positive, the tests aren't actually run.

[tsjk]

I'm confused by the state of this. Downloading and running the referenced binary and all is joy, but building (either normally, or statically using the Docker build system) the latest master (fdc253b) produces a binary that segfaults with SECCOMP enabled. What is the actual state of the art here?

[jopasserat]

Hey @tsjk, the master branch doesn't this fix yet as it doesn't pass all the tests in Travis.

Ideally we'd love to have a specific test for this fix, but not sure what would be representative. Any idea @jorge-lip ?

Also, @mirage335 reported the fix was not working on his specific configuration #106 (comment). Not reproduced since then.

We're already using the fix in @openmole without any problem so far.
We're building the static binaries via the Docker build and manually merge this branch in master along with @vincenthage 's Network cooperation mode

Really looking forward to have all these nice fixes/features merged in master and release the binaries!

[jopasserat]

On a separate note, do you think you could solve the merge conflict @jorge-lip?
It's nothing big, just a now unused variable since I merged next in master and an indentation glitch (https://github.com/proot-me/PRoot/pull/115/conflicts).

[tsjk]

Oh, I see. Thanks for your answer. I'm looking forward to the upcoming release. I'm using this with junest. In the meanwhile I've created a gist for myself that seems to produce a working and updated (x86_64) binary; https://gist.github.com/tsjk/10a9c64eae6e41ecd262a043b1a14907. You probably have something similar already.

[loveshack]

In case the data are useful, I tried the patch in a Fedora rawhide VM (linux "4.14.0-0.rc6.git2.1") and got the following failures -- more than the travis report:

CHECK test-2db65cd2 FAILED
CHECK test-d92b57ca FAILED
CHECK test-cdd39012 FAILED
CHECK test-0228fbe7 FAILED
CHECK test-c47aeb7d FAILED
CHECK test-a3e68988 FAILED

[romainreuillon]

Any hope to see this PR merged? What would it take to fix the test?

I would love to see a proot version with the portmap and the "kill on exit" support integrated in udocker.

[jorge-lip]

Hi in udocker I'm now using a different patch, there were still situations
were I was getting issues when spawning processes. I think I will make
a new PR with this patch against the master branch. I anyone wants to
try it udocker ships with a patched proot and the patch is in udocker
github.

[jorge-lip]

Are the patches for portmap and the "kill on exit" support already integrated in the proot
master branch ?

[romainreuillon]

Yes, they both have been merged.

[jopasserat]

that's great news @jorge-lip looking forward to that!