linux-kernel - Re: [PATCH] overlayfs: port all superblock creation logging to fsopen logs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxirsNEK24=u3K-X5A-EX80ofEx5ycjoqU4gocBoPVxbYw@mail.gmail.com>
Date: Wed, 6 Nov 2024 12:00:06 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Christian Brauner <brauner@...nel.org>, Miklos Szeredi <miklos@...redi.hu>
Cc: Aleksa Sarai <cyphar@...har.com>, Jan Kara <jack@...e.cz>, linux-unionfs@...r.kernel.org, 
	linux-fs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Karel Zak <kzak@...hat.com>
Subject: Re: [PATCH] overlayfs: port all superblock creation logging to fsopen logs

On Wed, Nov 6, 2024 at 10:59 AM Christian Brauner <brauner@...nel.org> wrote:
>
> On Wed, Nov 06, 2024 at 02:09:58PM +1100, Aleksa Sarai wrote:
> > overlayfs helpfully provides a lot of of information when setting up a
> > mount, but unfortunately when using the fsopen(2) API, a lot of this
> > information is mixed in with the general kernel log.
> >
> > In addition, some of the logs can become a source of spam if programs
> > are creating many internal overlayfs mounts (in runc we use an internal
> > overlayfs mount to protect the runc binary against container breakout
> > attacks like CVE-2019-5736, and xino_auto=on caused a lot of spam in
> > dmesg because we didn't explicitly disable xino[1]).
> >
> > By logging to the fs_context, userspace can get more accurate
> > information when using fsopen(2) and there is less dmesg spam for
> > systems where a lot of programs are using fsopen("overlay"). Legacy
> > mount(2) users will still see the same errors in dmesg as they did
> > before (though the prefix of the log messages will now be "overlay"
> > rather than "overlayfs").

I am not sure about the level of risk in this format change.
Miklos, WDYT?

> >
> > [1]: https://bbs.archlinux.org/viewtopic.php?pid=2206551
> >
> > Signed-off-by: Aleksa Sarai <cyphar@...har.com>
> > ---
>
> To me this sounds inherently useful! So I'm all for it.
>

[CC: Karel]

I am quite concerned about this.
I have a memory that Christian suggested to make this change back in the
original conversion to new mount API, but back then mount tool
did not print out the errors to users properly and even if it does
print out errors,
some script could very well be ignoring them.

My strong feeling is that suppressing legacy errors to kmsg should be opt-in
via the new mount API and that it should not be the default for libmount.
IMO, it is certainly NOT enough that new mount API is used by userspace
as an indication for the kernel to suppress errors to kmsg.
I have no problem with reporting errors to both userspace and kmsg
without opt-in from usersapce.

Furthermore, looking at the existing invalfc() calls in overlayfs, I see that
a few legacy pr_err() were converted to invalfc() with this commit
(signed off by myself):
819829f0319a ovl: refactor layer parsing helpers

I am not really sure if the discussion about suppressing the kmsg errors was
resolved or dismissed or maybe it only happened in my head??

Thanks,
Amir.