Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 14 May 2020 20:49:31 +0200
From: Mickaël Salaün <>
To: James Morris <>
Cc: Casey Schaufler <>,,
 Al Viro <>, Andy Lutomirski <>,
 Arnd Bergmann <>, Jann Horn <>,
 Jonathan Corbet <>, Kees Cook <>,
 Michael Kerrisk <>,
 Mickaël Salaün <>,
 "Serge E . Hallyn" <>, Shuah Khan <>,
 Vincent Dagonneau <>,,,,,,,,
Subject: Re: [PATCH v17 05/10] fs,landlock: Support filesystem access-control

On 14/05/2020 19:31, James Morris wrote:
> On Thu, 14 May 2020, Mickaël Salaün wrote:
>>> This needs to be converted to the LSM API via superblock blob stacking.
>>> See Casey's old patch: 
>> s_landlock_inode_refs is quite similar to s_fsnotify_inode_refs, but I
>> can do it once the superblock security blob patch is upstream. Is it a
>> blocker for now? What is the current status of lbs_superblock?
> Yes it is a blocker. Landlock should not be adding its own functions in 
> core code, it should be using the LSM API (and extending that as needed).

OK, I'll use that in the next series.

>> Anyway, we also need to have a call to landlock_release_inodes() in
>> generic_shutdown_super(), which does not fit the LSM framework, and I
>> think it is not an issue. Landlock handling of inodes is quite similar
>> to fsnotify.
> fsnotify is not an LSM.

Yes, so I'll need to add a new LSM hook for this (release) call, right?

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.