Hacker News new | ask | show | jobs
by qwertox 453 days ago
But

`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`).

1 comments

The former does not work for me, I have to add --exec. I can only assume it's because touch is in /usr/bin and so it needs permission to execute it from there.

It seems that using --ro or --rw at all makes --exec also mandatory.

well yeah you'll need --exec when you want to run binaries (unlike... cat?) I hope landlock adds support to bind --exec to actual directories, that'll be fun!
> you'll need --exec when you want to run binaries

well when wouldn't it do that? in what scenario could you even use this tool without needing to execute a binary?

running cat isn't a --exec for one :)
how so?

$ landrun --ro /usr/bin cat a

[landrun:error] 2025/03/22 23:50:16 permission denied

in this case doesn't have access to "a" wherever it is...

$ 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.