Re: autofs vs. Sun automount -- new fs proposal
Richard Gooch (rgooch@atnf.csiro.au)
Thu, 17 Dec 1998 10:31:37 +1100
Peter Benie writes:
> Alexander Viro writes ("Re: autofs vs. Sun automount -- new fs proposal"):
> >
> >
> > On Wed, 16 Dec 1998, Richard Gooch wrote:
> >
> > > The "clean" (or "fast", however you want to look at it) solution is to
> > > let the dentry layer do the work for you. For that you would need
> > > aliasing support for all dentries. Offhand, I don't see how you'd
> > > support a read-only option with a pure dentry scheme. In fact, I see
> > > the read-only requirement as a strong reason for doing it the "hard"
> > > way (i.e. not enhancing the VFS interface). A read-only lofs is great
> > > for securing ftp and tftp servers.
> >
> > Erm... Says who that intermediate dentries in stack can't have inodes
> > associated with them? Sure, pure vnode scheme is nice, but our one is also
> > usable.
>
> Alternatively, allow struct dentry and struct file to have a flag for
> read-only-filesystem.
No, I don't think that belongs in the dentry level. Read-only flags
belong in the superblock (for global effect) and per inode.
> I don't actually see the point of implementing a read-only loopback
> mount. There are already protection mechanisms in the kernel to
> prevent one user from writing to another user's files. If you need to
> run a program so that it cannot write to any files, just run the
> program under a different uid.
I guess you never notice the CERT security notices, then?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/