All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alexey Gladkov <gladkov.alexey@gmail.com>
Subject: Re: [GIT PULL] proc fixes v2 for v5.8-rc1
Date: Fri, 12 Jun 2020 15:02:16 -0500	[thread overview]
Message-ID: <87v9jwm4s7.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <CAHk-=wh7nZNf81QPcgpDh-0jzt2sOF3rdUEB0UcZvYFHDiMNkw@mail.gmail.com> (Linus Torvalds's message of "Fri, 12 Jun 2020 12:46:25 -0700")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Fri, Jun 12, 2020 at 12:34 PM Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>
>> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> What happened to that first version of the email? I never got it..

A little distracted I think.  I forgot to edit the above line out,
and v2 because it is my second pull request for a proc fix into
v5.8-rc1.

>> Looking at the code the fsnotify watch should have been removed by
>> fsnotify_sb_delete in generic_shutdown_super.
>
> Hmm. Correct. The new_inode_pseudo() is for things that don't have
> quotas, fsnotify or writeback.
>
> That was used somewhat intentionally on /proc, though. /proc certainly
> doesn't have quotas or writeback.

It also means we break our debugging by not putting inodes on the s_inodes list.

AKA this line in generic_shutdown_super is also depent on that behavior.
	if (!list_empty(&sb->s_inodes)) {
		printk("VFS: Busy inodes after unmount of %s. "
		   "Self-destruct in 5 seconds.  Have a nice day...\n",
		   sb->s_id);
	}

> And fsnotify on /proc seems a bit questionably too. Do people actually
> _do_ this and depend on it, or is this just about syzbot doing
> something odd and thus showing the problem?
>
> Anyway, I have pulled your fix, because I think it's reasonable and
> safe, but I do wonder if we should have kept the new_inode_pseudo(),
> and instead just make fsnotify say "you can't notify on an inode that
> isn't on the superblock list". Hmm?
>
> Is fsnotify on /proc really sensible? Do we actually generate any
> useful notifications?

I don't know of any proc code that does anything to make
fsnotify/inotify work.  Since changes to proc are not initialiated
through the vfs that probably means fsnotify is pretty much useless.

I have a sense that a use after free that anyone can trigger could be a
bit dangerous, and despite not being the only virtual filesystem in the
kernel proc is the only virtual filesystem that called new_inode_pseudo.

Eric


  reply	other threads:[~2020-06-12 20:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 14:47 [GIT PULL] proc changes for v5.8-rc1 Eric W. Biederman
2020-06-04 21:15 ` pr-tracker-bot
2020-06-10 21:45 ` [GIT PULL] proc fixes " Eric W. Biederman
2020-06-10 22:05   ` pr-tracker-bot
2020-06-12 19:29   ` [GIT PULL] proc fixes v2 " Eric W. Biederman
2020-06-12 19:46     ` Linus Torvalds
2020-06-12 20:02       ` Eric W. Biederman [this message]
2020-06-12 20:16         ` Linus Torvalds
2020-06-12 22:47           ` Eric W. Biederman
2020-06-12 19:50     ` pr-tracker-bot

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=87v9jwm4s7.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=adobriyan@gmail.com \
    --cc=gladkov.alexey@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.