From https://bugs.gentoo.org/930831#c9: """ Nitpick: net-p2p/kubo (f.k.a. ipfs) does basically the same thing - it downloads a "database migration" blob to /tmp/ and attempts to run it from there, which of course fails on a properly configured distro with tmp mounted noexec for security. """ Could someone investigate this?
Whenever I can I will set-up a proper system to test it, but grepping the source code only seems to show references to /tmp for running tests
I was in a rush before. I can confirm that the migration code downloads code into /tmp and tries to execute it: > Fetching with HTTP: "https://trustless-gateway.link/ipfs/QmZPedUiZNe6Gq9oDvoizuuCMVoeb7shwq9xKhysq7exMo/fs-repo-13-to-14/v1.0.0/fs-repo-13-to-14_v1.0.0_linux-amd64.tar.gz" > Downloaded and unpacked migration: /tmp/migrations788496017/fs-repo-13-to-14 (v1.0.0) > Running migration fs-repo-12-to-13 ... > => Running: /tmp/migrations788496017/fs-repo-12-to-13 -path=/root/.ipfs -verbose=true > The migrations of fs-repo failed: > migration fs-repo-12-to-13 failed: fork/exec /tmp/migrations788496017/fs-repo-12-to-13: permission denied > If you think this is a bug, please file an issue and include this whole log output. > https://github.com/ipfs/fs-repo-migrations > Error: migration fs-repo-12-to-13 failed: fork/exec /tmp/migrations788496017/fs-repo-12-to-13: permission denied There is a relevant issue already opened: https://github.com/ipfs/fs-repo-migrations/issues/148 As I understand it we should package the migration programs also, somehow.
Months later it appears there hasn't been any progress on this. I have to ask at this point, how functional the software is given that it sounds like there are doubts about it even working in relatively common system configurations. Is kubo something that is actually practical to have a package for? (And given the security concerns, do we want to encourage its use even if it is functional)?
I read a couple of users were using it. I use it myself to keep some pinned content in the server. The usability could be improved, but seems to work well. I have only seen one report about a user having a problem running it, after a few iterations the reporter never replied back and the issue was closed. About the security aspect, a user could, potentially, manually download the migrating repo and run it. The migration is made once, kubo doesn't actually require /tmp to be exec (once migration is done) to be running, so the security impact seems minimal. That said, next week I will dedicate some time to research this issue and how to improve the situation. At least it should be possible to package the migration blobs and make the kubo ebuild install them instead of the current behavior.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5aeff90072bfac4d49a518f0ef65d4c53b67dcae commit 5aeff90072bfac4d49a518f0ef65d4c53b67dcae Author: David Roman <davidroman96@gmail.com> AuthorDate: 2024-09-08 18:56:05 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-09-09 00:15:49 +0000 net-p2p/kubo: add fs-repo-migrations Bug: https://bugs.gentoo.org/930853 Signed-off-by: David Roman <davidroman96@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/38525 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> net-p2p/kubo/Manifest | 2 + net-p2p/kubo/kubo-0.29.0-r1.ebuild | 91 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 93 insertions(+)
