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@xxxxxxxxxxx/
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
