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?
–Günther
