| Message ID | 20221209082936.892416-2-roberto.sassu@huaweicloud.com (mailing list archive) |
|---|---|
| State | Under Review |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | [1/2] lsm: Fix description of fs_context_parse_param | expand |
On Fri, Dec 9, 2022 at 3:30 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > Align with the description of fs_context_parse_param in lsm_hooks.h, which > seems the right one according to the code. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > --- > Documentation/filesystems/mount_api.rst | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) I'm going to leave this patch as a "hold" for right now. The existing text is arguably not great, but I'm not really in love with the replacement text taken from the LSM hook comments; given the merge window opens in a couple of days, we don't have much time to fiddle with the wording so let's just hold this for a little bit. These comment corrections (which are very welcome!) have also reminded me that we really should move the hook comment blocks out of the header file and into security.c like every other kernel function. This should help increase their discoverability while also making it easier to maintain the comments over time. I'm going to post a first pass at this as soon as the merge window closes, and once that is done we can do further work to cleanup the descriptions and add more detail (including notes both for the other kernel subsystems that call the hooks and the LSM devs who provide implementations).
On Fri, 2022-12-09 at 12:41 -0500, Paul Moore wrote: > On Fri, Dec 9, 2022 at 3:30 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > Align with the description of fs_context_parse_param in lsm_hooks.h, which > > seems the right one according to the code. > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > --- > > Documentation/filesystems/mount_api.rst | 9 ++++----- > > 1 file changed, 4 insertions(+), 5 deletions(-) > > I'm going to leave this patch as a "hold" for right now. The existing > text is arguably not great, but I'm not really in love with the > replacement text taken from the LSM hook comments; given the merge > window opens in a couple of days, we don't have much time to fiddle > with the wording so let's just hold this for a little bit. > > These comment corrections (which are very welcome!) have also reminded > me that we really should move the hook comment blocks out of the > header file and into security.c like every other kernel function. > This should help increase their discoverability while also making it > easier to maintain the comments over time. I'm going to post a first > pass at this as soon as the merge window closes, and once that is done > we can do further work to cleanup the descriptions and add more detail > (including notes both for the other kernel subsystems that call the > hooks and the LSM devs who provide implementations). Ok, great! Roberto
diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst index eb358a00be27..fc3b12cb39d1 100644 --- a/Documentation/filesystems/mount_api.rst +++ b/Documentation/filesystems/mount_api.rst @@ -349,13 +349,12 @@ number of operations used by the new mount code for this purpose: struct fs_parameter *param); Called for each mount parameter, including the source. The arguments are - as for the ->parse_param() method. It should return 0 to indicate that - the parameter should be passed on to the filesystem, 1 to indicate that - the parameter should be discarded or an error to indicate that the - parameter should be rejected. + as for the ->parse_param() method. It might reject the mount parameter + with an error and might return 0, if the mount parameter is used by an LSM; + otherwise returns -ENOPARAM to pass it on to the filesystem. The value pointed to by param may be modified (if a string) or stolen - (provided the value pointer is NULL'd out). If it is stolen, 1 must be + (provided the value pointer is NULL'd out). If it is stolen, 0 must be returned to prevent it being passed to the filesystem. * ::