lkml.org 
[lkml]   [1998]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.147 / U:1.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site