Re: [REPOST PATCH v3 0/2] vfs: fix a mount table handling problem
From: Ian Kent
Date: Wed Sep 21 2022 - 01:36:02 EST
On 21/9/22 12:38, Ian Kent wrote:
On 21/9/22 09:20, Theodore Ts'o wrote:
On Tue, Sep 20, 2022 at 03:26:17PM +0800, Ian Kent wrote:
Whenever a mount has an empty "source" (aka mnt_fsname), the glibc
function getmntent incorrectly parses its input, resulting in reporting
incorrect data to the caller.
The problem is that the get_mnt_entry() function in glibc's
misc/mntent_r.c assumes that leading whitespace on a line can always
be discarded because it will always be followed by a # for the case
of a comment or a non-whitespace character that's part of the value
of the first field. However, this assumption is violated when the
value of the first field is an empty string.
This is fixed in the mount API code by simply checking for a pointer
that contains a NULL and treating it as a NULL pointer.
Why not simply have the mount API code disallow a zero-length "source"
/ mnt_fsname?
Hi Ted,
I suppose but it seems to me that, for certain file systems, mostly
pseudo file systems, the source isn't needed and is left out ... so
disallowing a zero length source could lead to quite a bit of breakage.
There's handling consistency too.
Ideally any empty string parameter will print "(none)" when listing
the proc mount tables. Mostly that happens in the proc code because
the field is NULL so if an empty string is specified due to having
to provide a positional parameter or for some other reason then
handling it by setting the zero length string to NULL in the mount
API is conveniently central. We could fix it in the proc code too
but then we might see cases get missed over time and we sacrifice
an opportunity to improve consistency.
To my mind continuing to allow it and dealing with what needs to be
done to make that work consistently seemed like the better long
term approach.
So based on that logic, sticky speaking, the ext patch shouldn't
retain the zero length string check but for now ...
Ian