Firejail: File transfer fails on large files

[laniakea64]

Xubuntu 18.04 64-bit
firejail self build from https://github.com/netblue30/firejail/commit/9eca281abbb24f97fdb92c06018cd2bd0a5b215e

$ firejail --version
firejail version 0.9.57

Compile time support:
        - AppArmor support is enabled
        - AppImage support is enabled
        - chroot support is enabled
        - file and directory whitelisting support is enabled
        - file transfer support is enabled
        - networking support is enabled
        - overlayfs support is enabled
        - private-home support is enabled
        - seccomp-bpf support is enabled
        - user namespace support is enabled
        - X11 sandboxing support is enabled

Steps to reproduce

1) check free space available in /run with df -Th, and create or find a file larger than that (On my system I used a 2 GB file)

2) run firejail --noprofile --overlay-tmpfs

3) Try to get the large file from (1) using firejail --get=<pid> path/to/the/file

Expected results

At (3), file should be copied from the overlay-tmpfs to the working directory

Actual results

At (3) it sits for a short time, then exits with status 1 without anything seeming to happen. I think it's related to the file being bigger than free space in /run because of this -

https://github.com/netblue30/firejail/blob/9eca281abbb24f97fdb92c06018cd2bd0a5b215e/src/firejail/ls.c#L316-L345

And indeed, a file does appear at /run/firejail/tmpget-... while the firejail --get=... command is running.

[chiraag-nataraj]

@laniakea64 I presume this is still a problem?

[laniakea64]

Yes, this still happens in self build from https://github.com/netblue30/firejail/commit/2323a45ca7875883784e6debd42caaee06042617

[rusty-snake]

@laniakea64 fixed by ccd0152? (#2820)

[laniakea64]

@laniakea64 fixed by ccd0152? (#2820)

I'm unable to fully test this in self build from https://github.com/netblue30/firejail/commit/580e49badab98972913301da6155d9e9d04d4465 because joining the sandbox doesn't seem to actually get me in the overlay-tmpfs -

1) run firejail --overlay-tmpfs --noprofile, note the parent pid

2) in the sandbox:

cd ~/Downloads
echo 'Test' > ./test.txt

3) in another terminal, run: firejail --join=<pid> (replacing <pid> with the parent pid)
When joined to the sandbox, run:

cd ~/Downloads
ls -la

And the file created in (2) is not there in the second terminal, it's only there in the first terminal.

Edit: It's not just not getting me in the sandbox's overlay-tmpfs. It's completely ignoring that aspect of the sandbox. In the second terminal, running

cd ~/Downloads
touch AAAAA

And a file called AAAAA appears in the real ~/Downloads, despite the sandbox being --overlay-tmpfs! :scream:

---

Actually, looks like --get= might not be affected by this, so maybe I can do a partial test? I set file-copy-limit 4096 in firejail.config, then tried to transfer a 2 GB file. Transfer failed, same as before. Transfer of the 5-byte test.txt file mentioned in this comment seems to work.

[laniakea64]

The regression reported in https://github.com/netblue30/firejail/issues/2301#issuecomment-524923730 is still there in self build from https://github.com/netblue30/firejail/commit/0ecbe8631c9102a4a6eda57e49b42bd14c856386 . Should I be filing it as a separate issue?

[laniakea64]

The regression reported in https://github.com/netblue30/firejail/issues/2301#issuecomment-524923730 is still there in self build from https://github.com/netblue30/firejail/commit/0ecbe8631c9102a4a6eda57e49b42bd14c856386 . Should I be filing it as a separate issue?

Since I didn't get a reply to this, I assume you rather it just be discussed here, even though it's not the same as the original issue.

The regression reported in https://github.com/netblue30/firejail/issues/2301#issuecomment-524923730 is still there in self build from https://github.com/netblue30/firejail/commit/b35c000fee9a4c1418a44e5a5a641bcf48f08345 . So I did a git bisect, and it pointed to 3e662f793df58fb44a26ba02193a99c26f554021 as the culprit.

[smitsohu]

@laniakea64 Thanks a lot! I'll try to figure out what's going wrong.

[laniakea64]

https://github.com/netblue30/firejail/issues/2301#issuecomment-524923730 seems fixed in self build from https://github.com/netblue30/firejail/commit/61bfaa69275f881d9ce890f2a15d93325eab110f . Thanks @smitsohu !

Back to the original issue: to finally properly answer @rusty-snake comment https://github.com/netblue30/firejail/issues/2301#issuecomment-524762431 - increasing file-copy-limit in /etc/firejail/firejail.config does not help here.

[atrent]

I had to copy large videos generated by Zoom... and I had not edited the limit in config beforehand, so I needed to solve the problem before turning off the program (thus losing tmp files).
I solved by copying files from the inside of the firejail sandbox, e.g. using Midnight Commander:
$ firejail --join= mc
and then copying files using a "Shell Link" (i.e., FISH file transfer) to the host.

(instead of 'firejail --get= ...')

[smitsohu]

Should be fixed in ccd01529adc647e75b618aa35c1742cffd17c694 and 27c136dcf4e84daee0c8886c869720ec9be7a594. Also there will be a cat option in 0.9.64 which can be used with shell redirection on files of arbitrary size.

Thanks for reporting the bug.

[laniakea64]

I'm unable to check it because build from 6ac40a597939989a55ab5465f548489e1ea4937d fails:

strip: 'src/man/preproc': No such file
make[1]: *** [Makefile:157: install-strip] Error 1
make: *** [Makefile:196: deb] Error 2

[rusty-snake]

I know build is failing ATM. Checkout 4762cf6855b989a7cc90caf5d1dc72cca6b1fd84 for now.

[laniakea64]

Sorry, this is still not fixed in self build from https://github.com/netblue30/firejail/commit/4762cf6855b989a7cc90caf5d1dc72cca6b1fd84 . --cat= + shell redirection does seem to work though.

Can this issue be reopened? Or is the answer to just use --cat= for large files?

Thanks :slightly_smiling_face:

[smitsohu]

Reopening! Sorry @laniakea64 I confused this with a different issue.

Or is the answer to just use --cat= for large files?

Maybe someone comes up with a better idea, but for now it seems that's going to be the answer.
I guess we could just reimplement the current --get using --cat under the hood.