* [PATCH 0/2] vfs: output mount_too_revealing() errors to fscontext @ 2025-08-06 4:48 Aleksa Sarai 2025-08-06 4:48 ` [PATCH 1/2] fscontext: add custom-prefix log helpers Aleksa Sarai 2025-08-06 4:48 ` [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai 0 siblings, 2 replies; 5+ messages in thread From: Aleksa Sarai @ 2025-08-06 4:48 UTC (permalink / raw) To: Alexander Viro, Christian Brauner, Jan Kara Cc: David Howells, linux-api, linux-kernel, linux-fsdevel, Aleksa Sarai It makes little sense for fsmount() to output the warning message when mount_too_revealing() is violated to kmsg. Instead, the warning should be output (with a "VFS" prefix) to the fscontext log. In addition, include the same log message for mount_too_revealing() when doing a regular mount for consistency. With the newest fsopen()-based mount(8) from util-linux, the error messages now look like # mount -t proc proc /tmp mount: /tmp: fsmount() failed: VFS: Mount too revealing. dmesg(1) may have more information after failed mount system call. which could finally result in mount_too_revealing() errors being easier for users to detect and understand. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> --- Aleksa Sarai (2): fscontext: add custom-prefix log helpers vfs: output mount_too_revealing() errors to fscontext fs/namespace.c | 6 ++++-- include/linux/fs_context.h | 18 ++++++++++++++---- 2 files changed, 18 insertions(+), 6 deletions(-) --- base-commit: 66639db858112bf6b0f76677f7517643d586e575 change-id: 20250805-errorfc-mount-too-revealing-5d9f670ba770 Best regards, -- Aleksa Sarai <cyphar@cyphar.com> ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/2] fscontext: add custom-prefix log helpers 2025-08-06 4:48 [PATCH 0/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai @ 2025-08-06 4:48 ` Aleksa Sarai 2025-08-06 4:48 ` [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai 1 sibling, 0 replies; 5+ messages in thread From: Aleksa Sarai @ 2025-08-06 4:48 UTC (permalink / raw) To: Alexander Viro, Christian Brauner, Jan Kara Cc: David Howells, linux-api, linux-kernel, linux-fsdevel, Aleksa Sarai Sometimes, errors associated with an fscontext come from the VFS or otherwise outside of the filesystem driver itself. However, the default logging of errorfc will always prefix the message with the filesystem name. So, add some *fcp() wrappers that allow for custom prefixes to be used when emitting information to the fscontext log. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> --- include/linux/fs_context.h | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h index 7773eb870039..671f031be173 100644 --- a/include/linux/fs_context.h +++ b/include/linux/fs_context.h @@ -186,10 +186,12 @@ struct fc_log { extern __attribute__((format(printf, 4, 5))) void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, ...); -#define __logfc(fc, l, fmt, ...) logfc((fc)->log.log, NULL, \ - l, fmt, ## __VA_ARGS__) -#define __plog(p, l, fmt, ...) logfc((p)->log, (p)->prefix, \ - l, fmt, ## __VA_ARGS__) +#define __logfc(fc, l, fmt, ...) \ + logfc((fc)->log.log, NULL, (l), (fmt), ## __VA_ARGS__) +#define __plogp(p, prefix, l, fmt, ...) \ + logfc((p)->log, (prefix), (l), (fmt), ## __VA_ARGS__) +#define __plog(p, l, fmt, ...) __plogp(p, (p)->prefix, l, fmt, ## __VA_ARGS__) + /** * infof - Store supplementary informational message * @fc: The context in which to log the informational message @@ -201,6 +203,8 @@ void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, #define infof(fc, fmt, ...) __logfc(fc, 'i', fmt, ## __VA_ARGS__) #define info_plog(p, fmt, ...) __plog(p, 'i', fmt, ## __VA_ARGS__) #define infofc(fc, fmt, ...) __plog((&(fc)->log), 'i', fmt, ## __VA_ARGS__) +#define infofcp(fc, prefix, fmt, ...) \ + __plogp((&(fc)->log), prefix, 'i', fmt, ## __VA_ARGS__) /** * warnf - Store supplementary warning message @@ -213,6 +217,8 @@ void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, #define warnf(fc, fmt, ...) __logfc(fc, 'w', fmt, ## __VA_ARGS__) #define warn_plog(p, fmt, ...) __plog(p, 'w', fmt, ## __VA_ARGS__) #define warnfc(fc, fmt, ...) __plog((&(fc)->log), 'w', fmt, ## __VA_ARGS__) +#define warnfcp(fc, prefix, fmt, ...) \ + __plogp((&(fc)->log), prefix, 'w', fmt, ## __VA_ARGS__) /** * errorf - Store supplementary error message @@ -225,6 +231,8 @@ void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, #define errorf(fc, fmt, ...) __logfc(fc, 'e', fmt, ## __VA_ARGS__) #define error_plog(p, fmt, ...) __plog(p, 'e', fmt, ## __VA_ARGS__) #define errorfc(fc, fmt, ...) __plog((&(fc)->log), 'e', fmt, ## __VA_ARGS__) +#define errorfcp(fc, prefix, fmt, ...) \ + __plogp((&(fc)->log), prefix, 'e', fmt, ## __VA_ARGS__) /** * invalf - Store supplementary invalid argument error message @@ -237,5 +245,7 @@ void logfc(struct fc_log *log, const char *prefix, char level, const char *fmt, #define invalf(fc, fmt, ...) (errorf(fc, fmt, ## __VA_ARGS__), -EINVAL) #define inval_plog(p, fmt, ...) (error_plog(p, fmt, ## __VA_ARGS__), -EINVAL) #define invalfc(fc, fmt, ...) (errorfc(fc, fmt, ## __VA_ARGS__), -EINVAL) +#define invalfcp(fc, prefix, fmt, ...) \ + (errorfcp(fc, prefix, fmt, ## __VA_ARGS__), -EINVAL) #endif /* _LINUX_FS_CONTEXT_H */ -- 2.50.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext 2025-08-06 4:48 [PATCH 0/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai 2025-08-06 4:48 ` [PATCH 1/2] fscontext: add custom-prefix log helpers Aleksa Sarai @ 2025-08-06 4:48 ` Aleksa Sarai 2025-08-06 5:41 ` Al Viro 1 sibling, 1 reply; 5+ messages in thread From: Aleksa Sarai @ 2025-08-06 4:48 UTC (permalink / raw) To: Alexander Viro, Christian Brauner, Jan Kara Cc: David Howells, linux-api, linux-kernel, linux-fsdevel, Aleksa Sarai It makes little sense for fsmount() to output the warning message when mount_too_revealing() is violated to kmsg. Instead, the warning should be output (with a "VFS" prefix) to the fscontext log. In addition, include the same log message for mount_too_revealing() when doing a regular mount for consistency. With the newest fsopen()-based mount(8) from util-linux, the error messages now look like # mount -t proc proc /tmp mount: /tmp: fsmount() failed: VFS: Mount too revealing. dmesg(1) may have more information after failed mount system call. which could finally result in mount_too_revealing() errors being easier for users to detect and understand. Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> --- fs/namespace.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/namespace.c b/fs/namespace.c index 55f28cebbe7d..b2146857cbbd 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -3820,8 +3820,10 @@ static int do_new_mount_fc(struct fs_context *fc, struct path *mountpoint, int error; error = security_sb_kern_mount(sb); - if (!error && mount_too_revealing(sb, &mnt_flags)) + if (!error && mount_too_revealing(sb, &mnt_flags)) { error = -EPERM; + errorfcp(fc, "VFS", "Mount too revealing"); + } if (unlikely(error)) { fc_drop_locked(fc); @@ -4547,7 +4549,7 @@ SYSCALL_DEFINE3(fsmount, int, fs_fd, unsigned int, flags, ret = -EPERM; if (mount_too_revealing(fc->root->d_sb, &mnt_flags)) { - pr_warn("VFS: Mount too revealing\n"); + errorfcp(fc, "VFS", "Mount too revealing"); goto err_unlock; } -- 2.50.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext 2025-08-06 4:48 ` [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai @ 2025-08-06 5:41 ` Al Viro 2025-08-06 6:06 ` Aleksa Sarai 0 siblings, 1 reply; 5+ messages in thread From: Al Viro @ 2025-08-06 5:41 UTC (permalink / raw) To: Aleksa Sarai Cc: Christian Brauner, Jan Kara, David Howells, linux-api, linux-kernel, linux-fsdevel On Wed, Aug 06, 2025 at 02:48:30PM +1000, Aleksa Sarai wrote: > error = security_sb_kern_mount(sb); > - if (!error && mount_too_revealing(sb, &mnt_flags)) > + if (!error && mount_too_revealing(sb, &mnt_flags)) { > error = -EPERM; > + errorfcp(fc, "VFS", "Mount too revealing"); > + } Hmm... For aesthetics sake, I'd probably do logging first; otherwise fine by me. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext 2025-08-06 5:41 ` Al Viro @ 2025-08-06 6:06 ` Aleksa Sarai 0 siblings, 0 replies; 5+ messages in thread From: Aleksa Sarai @ 2025-08-06 6:06 UTC (permalink / raw) To: Al Viro Cc: Christian Brauner, Jan Kara, David Howells, linux-api, linux-kernel, linux-fsdevel [-- Attachment #1: Type: text/plain, Size: 597 bytes --] On 2025-08-06, Al Viro <viro@zeniv.linux.org.uk> wrote: > On Wed, Aug 06, 2025 at 02:48:30PM +1000, Aleksa Sarai wrote: > > > error = security_sb_kern_mount(sb); > > - if (!error && mount_too_revealing(sb, &mnt_flags)) > > + if (!error && mount_too_revealing(sb, &mnt_flags)) { > > error = -EPERM; > > + errorfcp(fc, "VFS", "Mount too revealing"); > > + } > > Hmm... For aesthetics sake, I'd probably do logging first; otherwise > fine by me. Good point, I'll send a v2. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-08-06 6:06 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-08-06 4:48 [PATCH 0/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai 2025-08-06 4:48 ` [PATCH 1/2] fscontext: add custom-prefix log helpers Aleksa Sarai 2025-08-06 4:48 ` [PATCH 2/2] vfs: output mount_too_revealing() errors to fscontext Aleksa Sarai 2025-08-06 5:41 ` Al Viro 2025-08-06 6:06 ` Aleksa Sarai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).