Does Landlock not work with eCryptfs?

[Mickaël Salaün]

Hi Günther,

Thanks for the report, I confirm there is indeed a bug. I tested with a 
Debian distro:

ecryptfs-setup-private --nopwcheck --noautomount
ecryptfs-mount-private
# And then with the kernel's sample/landlock/sandboxer:
LL_FS_RO="/usr" LL_FS_RW="${HOME}/Private" sandboxer ls ~/Private
ls: cannot open directory '/home/user/Private': Permission denied

Actions other than listing a directory (e.g. creating files/directories, 
reading/writing to files) are controlled as expected. The issue might be 
that directories' inodes are not the same when listing the content of a 
directory or when creating new files/directories (which is weird). My 
hypothesis is that Landlock would then deny directory reading because 
the directory's inode doesn't match any rule. It might be related to the 
overlay nature of ecryptfs.

Tyler, do you have some idea?

FYI, I sent a patch fixing hostfs's inode management: 
https://lore.kernel.org/all/20230309165455.175131-2-mic@digikod.net/

Regards,
  Mickaël


On 19/03/2023 16:56, Günther Noack wrote:
> Hello!
> 
> I have a machine where the home directory is encrypted with eCryptfs,
> and it seems that Landlock is not working properly on eCryptfs files
> (but the same program works as expected on other mounts)?
> 
> 
> ## Problem description
> 
> Steps to reproduce:
> 
>    * Create a directory "subdir" in the current directory
>    * Enable Landlock but ask for "subdir" to be readable
>    * os.ReadDir(dir)
> 
> Observed result:
> 
> * os.ReadDir function fails when trying to open the file (verified with strace)
> 
> Expected result:
> 
> * os.ReadDir should work, because we asked for it to work when enabling Landlock
> 
> 
> ## Reproduction code
> 
> I have uploaded a reproduction program in Go to Github,
> which should be understandable also if you are primarily a C user:
> https://github.com/gnoack/llecryptfsrepro/blob/main/repro.go
> 
> To build and run the reproduction code, run:
> 
>    git clone https://github.com/gnoack/llecryptfsrepro
>    cd llecryptfsrepro
>    go build
>    ./llecryptfsrepro  # executes the three steps as above, check source code
> 
> You can invoke this binary in different file system types to see the difference.
> 
> 
> I have admittedly only checked it with a distribution kernel on
> Manjaro Linux: The Linux version is 6.2.2-1-MANJARO.
> 
> This looks like a bug to me?
> Is this a known issue?
> 
> Thanks,
> –Günther
>