Re: Landlock and O_PATH

> That is correct, the current Landlock implementation relies on the LSM 
> path hooks, and some filesystem actions are not handled. See the warning 
> section in 
> https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
> Opening a file or a directory with O_PATH cannot currently be denied 
> with Landlock and it is the same with AppArmor and Tomoyo. It may sound 
> scary but a file descriptor opened with O_PATH can only be used to refer 
> to a path (with *at syscalls), it does not give access to the underlying 
> file or directory content.
>
> You're right that it may be used as an oracle to find file or 
> directories, and this can also be done with syscalls such as chdir, 
> access or stat. The current goal of Landlock is to protect access to 
> data, which are in files, but it would be nice to also protect metadata 
> such as path existence.

Right, I see. That makes sense.

> I plan to fill this gap with new versions of Landlock, but I'll have to 
> patch the existing LSM framework.

Looking forward to this! I think it may be useful (considering Hyrum's
law) to document what is planned to be blocked in the future so that
application developers can use landlock safely now without worrying
about incompatibilities. It would kind of suck if applications would
break on newer kernels. That's my two cents anyway, I know you must
already be very busy.

Thanks,
Mukarram