From: Richard Weinberger <richard@nod.at>
To: Dongsu Park <dongsu@kinvolk.io>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Miklos Szeredi <mszeredi@redhat.com>,
Linux Containers <containers@lists.linux-foundation.org>,
Seth Forshee <seth.forshee@canonical.com>,
Alban Crequy <alban@kinvolk.io>,
"Eric W . Biederman" <ebiederm@xmission.com>,
Sargun Dhillon <sargun@sargun.me>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 02/11] mtd: Check permissions towards mtd block device inode when mounting
Date: Sat, 23 Dec 2017 13:56:51 +0100 [thread overview]
Message-ID: <65834980.AClogkzgvk@blindfold> (raw)
In-Reply-To: <CANxcAMtVqgLmQaTtfJocGGgsn5dSX2CDwzh6bwv6OnjUUwsTrg@mail.gmail.com>
Dongsu,
Am Samstag, 23. Dezember 2017, 13:18:30 CET schrieb Dongsu Park:
> Hi,
>
> On Fri, Dec 22, 2017 at 10:06 PM, Richard Weinberger
>
> <richard.weinberger@gmail.com> wrote:
> > Dongsu,
> >
> > On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park <dongsu@kinvolk.io> wrote:
> >> From: Seth Forshee <seth.forshee@canonical.com>
> >>
> >> Unprivileged users should not be able to mount mtd block devices
> >> when they lack sufficient privileges towards the block device
> >> inode. Update mount_mtd() to validate that the user has the
> >> required access to the inode at the specified path. The check
> >> will be skipped for CAP_SYS_ADMIN, so privileged mounts will
> >> continue working as before.
> >
> > What is the big picture of this?
> > Can in future an unprivileged user just mount UBIFS?
>
> I'm not sure I'm aware of all use cases w.r.t mtd & ubifs.
> To my understanding, in these days many container runtimes allow
> unprivileged users to run containers. (docker, lxc, runc, bubblewrap, etc)
> That's why the kernel should deal with additional permission checks
> that might have not been necessary in the past.
> This MTD patch is one of those special cases.
My fear is that a corner case is forgotten and all of a sudden someone can do
funky things with MTD in a container...
Thanks,
//richard
next prev parent reply other threads:[~2017-12-23 12:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1512741134.git.dongsu@kinvolk.io>
2017-12-22 14:32 ` [PATCH 01/11] block_dev: Support checking inode permissions in lookup_bdev() Dongsu Park
2017-12-22 18:59 ` Coly Li
2017-12-23 12:00 ` Dongsu Park
2017-12-23 3:03 ` Serge E. Hallyn
2017-12-22 14:32 ` [PATCH 02/11] mtd: Check permissions towards mtd block device inode when mounting Dongsu Park
2017-12-22 21:06 ` Richard Weinberger
2017-12-23 12:18 ` Dongsu Park
2017-12-23 12:56 ` Richard Weinberger [this message]
2017-12-23 3:05 ` Serge E. Hallyn
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=65834980.AClogkzgvk@blindfold \
--to=richard@nod.at \
--cc=alban@kinvolk.io \
--cc=containers@lists.linux-foundation.org \
--cc=dongsu@kinvolk.io \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mszeredi@redhat.com \
--cc=richard.weinberger@gmail.com \
--cc=sargun@sargun.me \
--cc=seth.forshee@canonical.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox