From: Al Viro <viro@zeniv.linux.org.uk>
To: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: David Laight <David.Laight@aculab.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Mount options may be silently discarded
Date: Mon, 28 Sep 2020 19:17:33 +0100 [thread overview]
Message-ID: <20200928181733.GC3421308@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CACE9dm8CPAFSY53Bm+vJvmh2m=Nm0FDe1mCtrwFAQnDE1p-XVw@mail.gmail.com>
On Mon, Sep 28, 2020 at 09:00:54PM +0300, Dmitry Kasatkin wrote:
> But why "we" should allow "discarding" failed part instead of failing
> with EFAULT as a whole?
Because there might very well be absolutely legitimate users of mount(2)
passing it something smaller than 4Kb immediately followed by an unmapped
area.
What can mount(2) do? It can't go up to the first \0 and stop there,
thanks to filesystems (NFS) that want to get struct some_shite filled
by userland. It can't require the entire 4Kb from the pointer passed
to mount(2) to be mapped and readable, simply because passing it
a string literal for e.g. ext4 mount can violate that requirement,
not to mention the result of strdup(3)/asprintf(3)/etc.
And it can't even tell which semantics to use by looking at the
filesystem type - NFS allows both the string and binary structure for
options.
prev parent reply other threads:[~2020-09-28 18:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 14:02 Mount options may be silently discarded Dmitry Kasatkin
2020-09-28 14:36 ` David Laight
2020-09-28 18:00 ` Dmitry Kasatkin
2020-09-28 18:17 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200928181733.GC3421308@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=David.Laight@aculab.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.