landrun --log-level debug --exec --ro /usr/bin --ro /usr/lib --rw /tmp touch /tmp/foo
Personally I don't like that --exec would allow binaries in /tmp to be executed as well...
landrun --log-level debug --exec --ro /usr/bin --ro /usr/lib --rw /tmp touch /tmp/foo
Personally I don't like that --exec would allow binaries in /tmp to be executed as well...
`landrun --ro /usr/bin --ro /lib --ro /lib64 --rw /path/to/dir touch /path/to/dir/newfile`
vs
`landrun --ro /usr/bin --ro /lib --ro /lib64 --exec /usr/bin/bash`
seems to indicate that `--exec` is only required if the command you're executing then uses an `exec`-call internally, which `bash` would need to be able to fork.
So `touch` should not need `--exec`, while `bash` should be able to run anything it can read (including that whitelisted `/tmp`).
It seems that using --ro or --rw at all makes --exec also mandatory.
well when wouldn't it do that? in what scenario could you even use this tool without needing to execute a binary?
$ landrun --ro /usr/bin cat a
[landrun:error] 2025/03/22 23:50:16 permission denied
$ landrun --ro /usr cat /usr/bin/ls | wc -l
400
executing ls (as in actual binary execution) will require --exec
$ landrun --ro /usr ls /usr/bin/
ls: cannot open directory '/usr/bin/': Permission denied
$ landrun --ro /usr --exec ls /usr/bin/
list of billions of files
note that I don't really love the --exec thingy, if it's not "on" by default it's just for sake of being explicit.
Update: there's a bug to limit "file access", which I'll fix asap.
Update2: Adding a --exec-path instead to limit executable, it wasn't the best idea to have a global --exec anyway
Update3: Have a look at V0.1.4, I think it's far cleaner now.
For added security, I'd create an ephemeral tmpfs disk for each landlocked invocation: obviously the program we're running has no business seeing what other processes may have put to /tmp.
And now you've just invented firejail.