All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Jann Horn <jannh@google.com>
Cc: dhowells@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
	raven@themaw.net, linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-block@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/7] vfs: Add superblock notifications
Date: Wed, 29 May 2019 13:58:39 +0100	[thread overview]
Message-ID: <24577.1559134719@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAG48ez2o1egR13FDd3=CgdXP_MbBsZM4SX=+aqvR6eheWddhFg@mail.gmail.com>

Jann Horn <jannh@google.com> wrote:

> It might make sense to require that the path points to the root inode
> of the superblock? That way you wouldn't be able to do this on a bind
> mount that exposes part of a shared filesystem to a container.

Why prevent that?  It doesn't prevent the container denizen from watching a
bind mount that exposes the root of a shared filesystem into a container.

It probably makes sense to permit the LSM to rule on whether a watch may be
emplaced, however.

> > +                       ret = add_watch_to_object(watch, s->s_watchers);
> > +                       if (ret == 0) {
> > +                               spin_lock(&sb_lock);
> > +                               s->s_count++;
> > +                               spin_unlock(&sb_lock);
> 
> Why do watches hold references on the superblock they're watching?

Fair point.  It was necessary at one point, but I don't think it is now.  I'll
see if I can remove it.  Note that it doesn't stop a superblock from being
unmounted and destroyed.

> > +                       }
> > +               }
> > +               up_write(&s->s_umount);
> > +               if (ret < 0)
> > +                       kfree(watch);
> > +       } else if (s->s_watchers) {
> 
> This should probably have something like a READ_ONCE() for clarity?

Note that I think I'll rearrange this to:

	} else {
		ret = -EBADSLT;
		if (s->s_watchers) {
			down_write(&s->s_umount);
			ret = remove_watch_from_object(s->s_watchers, wqueue,
						       s->s_unique_id, false);
			up_write(&s->s_umount);
		}
	}

I'm not sure READ_ONCE() is necessary, since s_watchers can only be
instantiated once and the watch list then persists until the superblock is
deactivated.  Furthermore, by the time deactivate_locked_super() is called, we
can't be calling sb_notify() on it as it's become inaccessible.

So if we see s->s_watchers as non-NULL, we should not see anything different
inside the lock.  In fact, I should be able to rewrite the above to:

	} else {
		ret = -EBADSLT;
		wlist = s->s_watchers;
		if (wlist) {
			down_write(&s->s_umount);
			ret = remove_watch_from_object(wlist, wqueue,
						       s->s_unique_id, false);
			up_write(&s->s_umount);
		}
	}

David

WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Jann Horn <jannh@google.com>
Cc: dhowells@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
	raven@themaw.net, linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-block@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/7] vfs: Add superblock notifications
Date: Wed, 29 May 2019 12:58:39 +0000	[thread overview]
Message-ID: <24577.1559134719@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAG48ez2o1egR13FDd3=CgdXP_MbBsZM4SX=+aqvR6eheWddhFg@mail.gmail.com>

Jann Horn <jannh@google.com> wrote:

> It might make sense to require that the path points to the root inode
> of the superblock? That way you wouldn't be able to do this on a bind
> mount that exposes part of a shared filesystem to a container.

Why prevent that?  It doesn't prevent the container denizen from watching a
bind mount that exposes the root of a shared filesystem into a container.

It probably makes sense to permit the LSM to rule on whether a watch may be
emplaced, however.

> > +                       ret = add_watch_to_object(watch, s->s_watchers);
> > +                       if (ret = 0) {
> > +                               spin_lock(&sb_lock);
> > +                               s->s_count++;
> > +                               spin_unlock(&sb_lock);
> 
> Why do watches hold references on the superblock they're watching?

Fair point.  It was necessary at one point, but I don't think it is now.  I'll
see if I can remove it.  Note that it doesn't stop a superblock from being
unmounted and destroyed.

> > +                       }
> > +               }
> > +               up_write(&s->s_umount);
> > +               if (ret < 0)
> > +                       kfree(watch);
> > +       } else if (s->s_watchers) {
> 
> This should probably have something like a READ_ONCE() for clarity?

Note that I think I'll rearrange this to:

	} else {
		ret = -EBADSLT;
		if (s->s_watchers) {
			down_write(&s->s_umount);
			ret = remove_watch_from_object(s->s_watchers, wqueue,
						       s->s_unique_id, false);
			up_write(&s->s_umount);
		}
	}

I'm not sure READ_ONCE() is necessary, since s_watchers can only be
instantiated once and the watch list then persists until the superblock is
deactivated.  Furthermore, by the time deactivate_locked_super() is called, we
can't be calling sb_notify() on it as it's become inaccessible.

So if we see s->s_watchers as non-NULL, we should not see anything different
inside the lock.  In fact, I should be able to rewrite the above to:

	} else {
		ret = -EBADSLT;
		wlist = s->s_watchers;
		if (wlist) {
			down_write(&s->s_umount);
			ret = remove_watch_from_object(wlist, wqueue,
						       s->s_unique_id, false);
			up_write(&s->s_umount);
		}
	}

David

  parent reply	other threads:[~2019-05-29 12:58 UTC|newest]

Thread overview: 131+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 16:01 [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications David Howells
2019-05-28 16:01 ` David Howells
2019-05-28 16:01 ` [PATCH 1/7] General notification queue with user mmap()'able ring buffer David Howells
2019-05-28 16:01   ` David Howells
2019-05-28 16:26   ` Greg KH
2019-05-28 16:26     ` Greg KH
2019-05-28 17:30   ` David Howells
2019-05-28 17:30     ` David Howells
2019-05-28 23:12     ` Greg KH
2019-05-28 23:12       ` Greg KH
2019-05-29 16:06     ` David Howells
2019-05-29 16:06       ` David Howells
2019-05-29 17:46       ` Jann Horn
2019-05-29 17:46         ` Jann Horn
2019-05-29 21:02       ` David Howells
2019-05-29 21:02         ` David Howells
2019-05-31 11:14         ` Peter Zijlstra
2019-05-31 11:14           ` Peter Zijlstra
2019-05-31 12:02         ` David Howells
2019-05-31 12:02           ` David Howells
2019-05-31 13:26           ` Peter Zijlstra
2019-05-31 13:26             ` Peter Zijlstra
2019-05-31 14:20           ` David Howells
2019-05-31 14:20             ` David Howells
2019-05-31 16:44             ` Peter Zijlstra
2019-05-31 16:44               ` Peter Zijlstra
2019-05-31 17:12             ` David Howells
2019-05-31 17:12               ` David Howells
2019-06-17 16:24               ` Peter Zijlstra
2019-06-17 16:24                 ` Peter Zijlstra
2019-05-29 23:09       ` Greg KH
2019-05-29 23:09         ` Greg KH
2019-05-29 23:11       ` Greg KH
2019-05-29 23:11         ` Greg KH
2019-05-30  9:50         ` Andrea Parri
2019-05-30  9:50           ` Andrea Parri
2019-05-31  8:35           ` Peter Zijlstra
2019-05-31  8:35             ` Peter Zijlstra
2019-05-31  8:47       ` Peter Zijlstra
2019-05-31  8:47         ` Peter Zijlstra
2019-05-31 12:42       ` David Howells
2019-05-31 12:42         ` David Howells
2019-05-31 14:55       ` David Howells
2019-05-31 14:55         ` David Howells
2019-05-28 19:14   ` Jann Horn
2019-05-28 19:14     ` Jann Horn
2019-05-28 22:28   ` David Howells
2019-05-28 22:28     ` David Howells
2019-05-28 23:16     ` Jann Horn
2019-05-28 23:16       ` Jann Horn
2019-05-28 16:02 ` [PATCH 2/7] keys: Add a notification facility David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 16:02 ` [PATCH 3/7] vfs: Add a mount-notification facility David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 20:06   ` Jann Horn
2019-05-28 20:06     ` Jann Horn
2019-05-28 23:04   ` David Howells
2019-05-28 23:04     ` David Howells
2019-05-28 23:23     ` Jann Horn
2019-05-28 23:23       ` Jann Horn
2019-05-29 11:16     ` David Howells
2019-05-29 11:16       ` David Howells
2019-05-28 23:08   ` David Howells
2019-05-28 23:08     ` David Howells
2019-05-29 10:55   ` David Howells
2019-05-29 10:55     ` David Howells
2019-05-29 11:00   ` David Howells
2019-05-29 11:00     ` David Howells
2019-05-29 15:53     ` Casey Schaufler
2019-05-29 15:53       ` Casey Schaufler
2019-05-29 16:12       ` Jann Horn
2019-05-29 16:12         ` Jann Horn
2019-05-29 17:04         ` Casey Schaufler
2019-05-29 17:04           ` Casey Schaufler
2019-06-03 16:30         ` David Howells
2019-06-03 16:30           ` David Howells
2019-05-29 17:13       ` Andy Lutomirski
2019-05-29 17:13         ` Andy Lutomirski
2019-05-29 17:46         ` Casey Schaufler
2019-05-29 17:46           ` Casey Schaufler
2019-05-29 18:11           ` Jann Horn
2019-05-29 18:11             ` Jann Horn
2019-05-29 19:28             ` Casey Schaufler
2019-05-29 19:28               ` Casey Schaufler
2019-05-29 19:47               ` Jann Horn
2019-05-29 19:47                 ` Jann Horn
2019-05-29 20:50                 ` Casey Schaufler
2019-05-29 20:50                   ` Casey Schaufler
2019-05-29 23:12           ` Andy Lutomirski
2019-05-29 23:12             ` Andy Lutomirski
2019-05-29 23:56             ` Casey Schaufler
2019-05-29 23:56               ` Casey Schaufler
2019-05-28 16:02 ` [PATCH 4/7] vfs: Add superblock notifications David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 20:27   ` Jann Horn
2019-05-28 20:27     ` Jann Horn
2019-05-29 12:58   ` David Howells [this message]
2019-05-29 12:58     ` David Howells
2019-05-29 14:16     ` Jann Horn
2019-05-29 14:16       ` Jann Horn
2019-05-28 16:02 ` [PATCH 5/7] fsinfo: Export superblock notification counter David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 16:02 ` [PATCH 6/7] block: Add block layer notifications David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 20:37   ` Jann Horn
2019-05-28 20:37     ` Jann Horn
2019-05-28 16:02 ` [PATCH 7/7] Add sample notification program David Howells
2019-05-28 16:02   ` David Howells
2019-05-28 23:58 ` [RFC][PATCH 0/7] Mount, FS, Block and Keyrings notifications Greg KH
2019-05-28 23:58   ` Greg KH
2019-05-29  6:33 ` Amir Goldstein
2019-05-29  6:33   ` Amir Goldstein
2019-05-29  6:33   ` Amir Goldstein
2019-05-29 14:25   ` Jan Kara
2019-05-29 14:25     ` Jan Kara
2019-05-29 15:10     ` Greg KH
2019-05-29 15:10       ` Greg KH
2019-05-29 15:53     ` Amir Goldstein
2019-05-29 15:53       ` Amir Goldstein
2019-05-30 11:00       ` Jan Kara
2019-05-30 11:00         ` Jan Kara
2019-06-04 12:33     ` David Howells
2019-06-04 12:33       ` David Howells
2019-05-29  6:45 ` David Howells
2019-05-29  6:45   ` David Howells
2019-05-29  7:40   ` Amir Goldstein
2019-05-29  7:40     ` Amir Goldstein
2019-05-29  9:09 ` David Howells
2019-05-29  9:09   ` David Howells
2019-05-29 15:41   ` Casey Schaufler
2019-05-29 15:41     ` Casey Schaufler

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=24577.1559134719@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=jannh@google.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=raven@themaw.net \
    --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.