Messages in this thread | | | Date | Thu, 17 Dec 1998 10:31:37 +1100 | From | Richard Gooch <> | Subject | Re: autofs vs. Sun automount -- new fs proposal |
| |
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/
| |