From: Bryan Steele Subject: Re: [got-portable] landlock support, second try To: gameoftrees@openbsd.org Date: Tue, 8 Feb 2022 00:14:25 -0500 On Tue, Feb 08, 2022 at 12:00:05AM -0500, Bryan Steele wrote: > On Sun, Feb 06, 2022 at 04:59:05PM +0100, Omar Polo wrote: > > Thomas Adam writes: > > > > > On Sun, Feb 06, 2022 at 12:06:27PM +0100, Omar Polo wrote: > > >> here's a revised diff. it's equivalent in practice to the previous one, > > >> but hopefully less scary :) > > > > > > Thanks for this. I have no means of testing this though (the kernel version I > > > have here on Arch Linux doesn't seem to offer Landlock) but I have a few > > > comment in-line below. > > > > unfortunately it doesn't seem to be that much available yet. I can > > confirm that fedora has it, and I'm told nixos ship with landlock > > enabled too. > > > > I just tried on a devuan ceres (unstable) vm and they ship > > linux/landlock.h, but the actual kernel has landlock disabled! I've > > added a check for ENOSYS and ENOTSUP to handle this situation where > > landlock was found at compile time but it's not present at runtime. > > I'd agrue that in the ENOTSUP case it shouldn't fail silently and > should instead return an error, that way distributions attempting > to ship packages have a chance of catching it, rather than shipping > out binaries that don't actually provide any sort of protection. > > At least in that case the distros adding --disable-landlock will be > easier spot as well. I guess that's not actually even a flag, but I guess they might try and override cv_header_linux_landlock_h=no during builds. Still if it's always going to get compiled on Linux, there should be some kind of indication it is actually doing something and isn't just a no-op. I know this has already been committed, but just had a chance to reply.