RE: FW: gnome

["Fox, Kevin M" <kmfox bhi010 bhi-erc com>]

As to why should it be in the kernel. It is the kernels job. Writeing a VFS
library requires programs to be spacificly programmed for it and it bypasses
security. The reason why normal users cant mount is because of security. If
you go around that it can be a really bad thing. Root MUST be able to
restrict filesystems. Root MUST be able to say what user can do what.
Implamenting libvfs as an NFS server allows root to control who can do what
and removes the need for a program to be modified to use the libvfs library.


And as to the ability to run GNOME on other unixes, using an NFS server for
VFS solves that problem. Plus it has the advantage of working with ALL
programs on the unix. Programs like CP MV and BASH will automaticlly work.

> -----Original Message-----
> From:	Ian Wells [SMTP:I.Wells@tarragon-et.co.uk]
> Sent:	Thursday, December 10, 1998 2:36 AM
> To:	Fox, Kevin M
> Subject:	Re: FW: gnome
> 
> Fox, Kevin M writes:
>  > If you use a VFS NFS server it should solve the need to use the VFS
> library
>  > in a program
>  > > This strikes me as solving all arguments for using VFS. It speeds up
>  > > programs because thay dont have to go through 2 librarys, libvfs and
> the
>  > > standard library, it provides the flexability and programs dont have
> to be
>  > > recompiled thus working on operating systems that are closed sorce.
> 
> Um, I think you keep asking the wrong question.  You keep asking,
> effectively, "Why isn't this in the kernel?"  Perhaps what you
> should be asking instead is "Why *should* this be in the kernel?"
> 
> The difference is quite important.  Why are filesystems usually in the 
> kernel?  
> 
> Well, firstly because the kernel enforces read-write protection.  You
> don't want this on a tar filesystem, because the permissions on the
> tar file itself dictate the accessibility of what's in the file, not
> what the permissions flags stored in the file say.
> 
> Secondly, because filesystems hold special status in the kernel.
> Above all, they're where executables are executed from.  They're also
> the only way of improving one's protection level - if you're a
> normal-user program, you can change your access by running a setuid
> file.
> 
> Thirdly, because device files can live there.  A tar file can also
> contain device files, but you wouldn't want them to be real device
> files because it bypasses the protection on the /dev files.
> 
> All of these come down to a matter of permission.  The kernel enforces
> user-to-user file protection which a user process can't get around.
> If protection was in a user-level library, processes could bypass it,
> which is why it's always implemented in the kernel of a Unix system
> and why kernel code is always made unwritable by user processes.  If
> you let a user process do things like mounting, which are privileged
> operations because of their permission-controlling effect, they can
> still bypass it. NFS mounting gets round the kernel code problem but
> the security bypassing problem remains.
> 
> However, libvfs implements filing which doesn't have, or need,
> protection, and implements it as the user who wants to look at the
> file.  So it doesn't *need* to be in the kernel, and implementing it
> as user-level code avoids any security implications of putting it in
> the kernel or using superuser programs.
> 
> Furthermore (although per-process mounts would get round this) Unix
> mounts a filesystem for every process, so when you go peeking into a
> file you have to mount it in a place which is exposed to every other
> process.  This is particularly unattractive.
> 
> Finally, a confession of self-interest: I like to be able to run GNOME
> on other Unixes.  It shouldn't be tied to Linux, and it doesn't have
> to be tied to Linux.  I also like to be able to install it as a normal
> user, rather than root.  (I don't *have* root access on some boxes I
> use.)  I don't see why file operations which I have permission to do
> as a normal user should require root access.
> 
> -- 
> Ian.