bind mounts and options

bind mounts and options

[Attila Kinali]

Moin,

I wanted to ask whether there is a technical reason
why bind mounts do not honour options passed to it.

It would be a really cool feature to be able
to mount certain parts of the file system into
a chroot enviroment read only, so that it couldnt
be modified, but still be changed by a user outside
the chroot.

At least i've seen a few patches floating around
that add at least the ro option, so i guess it should
not be too hard.

			Attila Kinali

Re: bind mounts and options

[Ram Pai]

On Fri, 2005-10-28 at 06:13, Attila Kinali wrote:
> Moin,
> 
> I wanted to ask whether there is a technical reason
> why bind mounts do not honour options passed to it.
> 
> It would be a really cool feature to be able
> to mount certain parts of the file system into
> a chroot enviroment read only, so that it couldnt
> be modified, but still be changed by a user outside
> the chroot.
> 
> At least i've seen a few patches floating around
> that add at least the ro option, so i guess it should
> not be too hard.
A bind mount to a different location creates a new mount-instance of the
underlying filesytem. 
If the underlying filesystem can handle multiple instances of itself
being mounted with different read-options, this should be possible.
But I dont think currently that is the case. 

RP


> 
> 			Attila Kinali
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bind mounts and options

[Shaya Potter]

On Fri, 2005-10-28 at 11:18 -0700, Ram Pai wrote:
> On Fri, 2005-10-28 at 06:13, Attila Kinali wrote:
> > Moin,
> > 
> > I wanted to ask whether there is a technical reason
> > why bind mounts do not honour options passed to it.
> > 
> > It would be a really cool feature to be able
> > to mount certain parts of the file system into
> > a chroot enviroment read only, so that it couldnt
> > be modified, but still be changed by a user outside
> > the chroot.
> > 
> > At least i've seen a few patches floating around
> > that add at least the ro option, so i guess it should
> > not be too hard.
> A bind mount to a different location creates a new mount-instance of the
> underlying filesytem. 
> If the underlying filesystem can handle multiple instances of itself
> being mounted with different read-options, this should be possible.
> But I dont think currently that is the case. 

one could create a really simple stackable file system that did this,
use fist, generate base0fs, and edit the code to disallow all function
paths that can change the filesystem.  It's not a complete situation, as
meta data (access time...) would still be updated.

Re: bind mounts and options

[Attila Kinali]

On Fri, 28 Oct 2005 11:18:34 -0700
Ram Pai <linuxram@us.ibm.com> wrote:

> A bind mount to a different location creates a new mount-instance of the
> underlying filesytem. 
> If the underlying filesystem can handle multiple instances of itself
> being mounted with different read-options, this should be possible.
> But I dont think currently that is the case. 

Well, the patch at http://www.13thfloor.at/patches/ seems to do
that. Though i have to admit that i hardly know anything about the
vfs system, so i cannot say whether it does it the right way
and whether it works in all cases.

			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu