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 <thomas@xteddy.org> 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.