On 20/03/2023 18:15, Günther Noack wrote:
Hello! On Sun, Mar 19, 2023 at 10:00:46PM +0100, Mickaël Salaün wrote: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?I had a hunch, and found out that the example can be made to work by granting the LANDLOCK_ACCESS_FS_READ_DIR right on the place where the *encrypted* version of that home directory lives: err := landlock.V1.RestrictPaths( landlock.RODirs(dir), landlock.PathAccess(llsys.AccessFSReadDir, "/home/.ecryptfs/gnoack/.Private"), ) It does seem a bit like eCryptfs it calling security_file_open() under the hood for the encrypted version of that file? Is that correct?
Yes, that's right, the lower directory is used to list the content of the ecryptfs directory: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ecryptfs/file.c#n112 iterate_dir(lower_file, …)
