On 3/26/20 4:06 PM, Daniel Colascione wrote:
This change adds two new functions, anon_inode_getfile_secure and anon_inode_getfd_secure, that create anonymous-node files with individual non-S_PRIVATE inodes to which security modules can apply policy. Existing callers continue using the original singleton-inode kind of anonymous-inode file. We can transition anonymous inode users to the new kind of anonymous inode in individual patches for the sake of bisection and review. The new functions accept an optional context_inode parameter that callers can use to provide additional contextual information to security modules, e.g., indicating that one anonymous struct file is a logical child of another, allowing a security model to propagate security information from one to the other. Signed-off-by: Daniel Colascione <dancol@xxxxxxxxxx> ---
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c index 89714308c25b..024059e333dc 100644 --- a/fs/anon_inodes.c +++ b/fs/anon_inodes.c @@ -55,75 +55,135 @@ static struct file_system_type anon_inode_fs_type = { +static struct inode *anon_inode_make_secure_inode( + const char *name, + const struct inode *context_inode, + const struct file_operations *fops)
fops argument can be removed here too, unused now by this function.
/** - * anon_inode_getfd - creates a new file instance by hooking it up to an - * anonymous inode, and a dentry that describe the "class" - * of the file + * anon_inode_getfile_secure - creates a new file instance by hooking + * it up to a new anonymous inode and a + * dentry that describe the "class" of the + * file. Make it possible to use security + * modules to control access to the + * new file. * * @name: [in] name of the "class" of the new file * @fops: [in] file operations for the new file * @priv: [in] private data for the new file (will be file's private_data) - * @flags: [in] flags + * @flags: [in] flags for the file + * @anon_inode_flags: [in] flags for anon_inode*
anon_inode_flags leftover from prior version of the patch, not an argument in the current code. Likewise, the "for the file" addendum to the @flags argument description is a leftover and not needed.
> + * Creates a new file by hooking it on an unspecified inode. This is > + * useful for files that do not need to have a full-fledged inode in > + * order to operate correctly. All the files created with > + * anon_inode_getfile_secure() will have distinct inodes, avoiding > + * code duplication for the file/inode/dentry setup. The two preceding sentences directly contradict each other.
+/** + * anon_inode_getfile - creates a new file instance by hooking it up + * to an anonymous inode and a dentry that + * describe the "class" of the file.
This would be identical to the original except for different word wrapping. Probably a leftover from prior version of the patch where you were modifying the existing interface. Recommend reverting such changes to minimize unnecessary noise in your diff and meke it easier to tell what changes are real.
+ * + * @name: [in] name of the "class" of the new file + * @fops: [in] file operations for the new file + * @priv: [in] private data for the new file (will be file's private_data) + * @flags: [in] flags for the file * - * Creates a new file by hooking it on a single inode. This is useful for files + * Creates a new file by hooking it on an unspecified inode. This is useful for files
Unnecessary difference here; this interface does use a single inode.
@@ -146,6 +207,57 @@ int anon_inode_getfd(const char *name, const struct file_operations *fops, put_unused_fd(fd); return error; } + +/** + * anon_inode_getfd_secure - creates a new file instance by hooking it + * up to a new anonymous inode and a dentry + * that describe the "class" of the file. + * Make it possible to use security modules + * to control access to the new file. + * + * @name: [in] name of the "class" of the new file + * @fops: [in] file operations for the new file + * @priv: [in] private data for the new file (will be file's private_data) + * @flags: [in] flags + *
> + * Creates a new file by hooking it on an unspecified inode. This is > + * useful for files that do not need to have a full-fledged inode in > + * order to operate correctly. All the files created with > + * anon_inode_getfile_secure() will have distinct inodes, avoiding > + * code duplication for the file/inode/dentry setup. The two preceding sentences contradict each other.