From: Dave Hansen <haveblue@...>
Subject: [PATCH 00/24] Read-only bind mounts
Date: Sep 17, 2:27 pm 2007
If we can't pull the entire series into -mm, can we just put the
first three patches for now? They can stand on their own.
---
Why do we need r/o bind mounts?
This feature allows a read-only view into a read-write filesystem.
In the process of doing that, it also provides infrastructure for
keeping track of the number of writers to any given mount.
This has a number of uses. It allows chroots to have parts of
filesystems writable. It will be useful for containers in the future
because users may have root inside a container, but should not
be allowed to write to somefilesystems. This also replaces
patches that vserver has had out of the tree for several years.
It allows security enhancement by making sure that parts of
your filesystem read-only (such as when you don't trust your
FTP server), when you don't want to have entire new filesystems
mounted, or when you want atime selectively updated.
I've been using the following script to test that the feature is
working as desired. It takes a directory and makes a regular
bind and a r/o bind mount of it. It then performs some normal
filesystem operations on the three directories, including ones
that are expected to fail, like creating a file on the r/o
mount.
Signed-off-by: Dave Hansen
-
From: Christoph Hellwig <hch@...>
Subject: Re: [PATCH 00/24] Read-only bind mounts
Date: Sep 19, 1:44 pm 2007
On Mon, Sep 17, 2007 at 11:27:18AM -0700, Dave Hansen wrote:
> If we can't pull the entire series into -mm, can we just put the
> first three patches for now? They can stand on their own.
Yes, they're kinda a series of their own. But I still think we really
want this in -mm. As we've seen on the kernel summit there's a pretty
desparate need for it. And there's not many changes in this area in
-mm, maybe the unprivilegued mounts. I'd personally prioritize the
r/o bindmounts over them as they're more needed and we need more reviewing
of the unprivilegued mounts (I'll try to come back to that soon).
FYI: the series you sent out are missing the last two patches, and while
they compile as-is they're actually missing the interesting part :)
-
From: Andrew Morton <akpm@...>
Subject: Re: [PATCH 00/24] Read-only bind mounts
Date: Sep 19, 5:24 pm 2007
On Wed, 19 Sep 2007 18:44:18 +0100
Christoph Hellwig wrote:
> On Mon, Sep 17, 2007 at 11:27:18AM -0700, Dave Hansen wrote:
> > If we can't pull the entire series into -mm, can we just put the
> > first three patches for now? They can stand on their own.
>
> Yes, they're kinda a series of their own. But I still think we really
> want this in -mm. As we've seen on the kernel summit there's a pretty
> desparate need for it. And there's not many changes in this area in
> -mm, maybe the unprivilegued mounts. I'd personally prioritize the
> r/o bindmounts over them as they're more needed and we need more reviewing
> of the unprivilegued mounts (I'll try to come back to that soon).
What's the situation on unprivileged mounts? iirc, it's all a bit stuck.
If unpriv-mounts code isn't going to go into mainline ahead of r/o bind
mounts then it'd make a big mess to prepare the r/o bind mount patches on
top of unprivileged mounts.
It sounds like a better approach would be for me to merge the r/o bind
mounts code and to drop (or maybe rework) the unprivileged mounts patches
-
From: Dave Hansen <haveblue@...>
Subject: Re: [PATCH 00/24] Read-only bind mounts
Date: Sep 19, 5:56 pm 2007
On Wed, 2007-09-19 at 14:24 -0700, Andrew Morton wrote:
> On Wed, 19 Sep 2007 18:44:18 +0100
> Christoph Hellwig wrote:
>
> > On Mon, Sep 17, 2007 at 11:27:18AM -0700, Dave Hansen wrote:
> > > If we can't pull the entire series into -mm, can we just put the
> > > first three patches for now? They can stand on their own.
> >
> > Yes, they're kinda a series of their own. But I still think we really
> > want this in -mm. As we've seen on the kernel summit there's a pretty
> > desparate need for it. And there's not many changes in this area in
> > -mm, maybe the unprivilegued mounts. I'd personally prioritize the
> > r/o bindmounts over them as they're more needed and we need more reviewing
> > of the unprivilegued mounts (I'll try to come back to that soon).
>
> What's the situation on unprivileged mounts? iirc, it's all a bit stuck.
>
> If unpriv-mounts code isn't going to go into mainline ahead of r/o bind
> mounts then it'd make a big mess to prepare the r/o bind mount patches on
> top of unprivileged mounts.
>
> It sounds like a better approach would be for me to merge the r/o bind
> mounts code and to drop (or maybe rework) the unprivileged mounts patches
I actually don't think they collided too much. There were a couple of
patches, like maybe 2 or 3 that needed any futzing at all.
I'll cook up a set straight on top of mainline if that helps.
-- Dave
-
From: Andrew Morton <akpm@...>
Subject: Re: [PATCH 00/24] Read-only bind mounts
Date: Sep 19, 6:06 pm 2007
On Wed, 19 Sep 2007 14:56:27 -0700
Dave Hansen wrote:
> On Wed, 2007-09-19 at 14:24 -0700, Andrew Morton wrote:
> > On Wed, 19 Sep 2007 18:44:18 +0100
> > Christoph Hellwig wrote:
> >
> > > On Mon, Sep 17, 2007 at 11:27:18AM -0700, Dave Hansen wrote:
> > > > If we can't pull the entire series into -mm, can we just put the
> > > > first three patches for now? They can stand on their own.
> > >
> > > Yes, they're kinda a series of their own. But I still think we really
> > > want this in -mm. As we've seen on the kernel summit there's a pretty
> > > desparate need for it. And there's not many changes in this area in
> > > -mm, maybe the unprivilegued mounts. I'd personally prioritize the
> > > r/o bindmounts over them as they're more needed and we need more reviewing
> > > of the unprivilegued mounts (I'll try to come back to that soon).
> >
> > What's the situation on unprivileged mounts? iirc, it's all a bit stuck.
> >
> > If unpriv-mounts code isn't going to go into mainline ahead of r/o bind
> > mounts then it'd make a big mess to prepare the r/o bind mount patches on
> > top of unprivileged mounts.
> >
> > It sounds like a better approach would be for me to merge the r/o bind
> > mounts code and to drop (or maybe rework) the unprivileged mounts patches
>
> I actually don't think they collided too much. There were a couple of
> patches, like maybe 2 or 3 that needed any futzing at all.
>
> I'll cook up a set straight on top of mainline if that helps.
>
That sounds good, thanks.
There may be collisions with unionfs too, but if that happens in a
non-trivial way I may just drop unionfs - it doesn't look like it's
going to get there in its present form.
-
There are some FUSE file
There are some FUSE file systems that allow you to do this already.
FUSE needs kernel support
FUSE needs kernel support for unprivileged mounts, that's why the FUSE author implemented this kernel functionality.
Unprivledged mounting?
How long has this "unprivledged mounting" thing been around? Where can I find more information on it?
I remember asking why such a thing wasn't an option in Linux a few years ago, and being told it would be impossible to implement on a UNIX-like system. The conversation in question was roughly: "Why can't a normal user mount a loopback interface without an entry in /etc/fstab?" "Because then he'd be able to claim files were suid root and do anything!" "Why wouldn't it just say all the files mounted were owned by him anyway?" "That would be impossible. You're welcome to try."
Is that the sort of thing that unprivledged mounting relates to?
unprivileged mounting patches
Here's the last time the patches were posted to the lkml: overview, patch 1, patch 2, patch 3, patch 4, patch 5, patch 6, patch 7, patch 8, patch 9, patch 10.
This is a top idea
This is a top idea