RE: FW: gnome

Er, this was actually a private email, which I didn't send to the
list.  But if you prefer to air your dirty laundry in public....

Fox, Kevin M writes:
 > 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 

Yes and no.  Sometimes this is appropriate - any program which *knows*
it's opening tar files, like Mignight Commander, probably wants to be
aware it's just moved into a file in any case, and so using a library
is the correct way to do things.  Where it's not appropriate, there is
(or was, anyway) a library which overrides functions such as open(),
read(), etc. transparently to the program using the dynamic linker.

 >                                                              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.

Er, yes and no.  The point I made below is that the root user's job is 
to control the kernel's enforcement of security.  Where the kernel
should be controlling who can use what file in a filesystem, a root
user must mount it.  Where you need to run files from a filesystem,
a root user must also mount it - otherwise setuid, for instance, won't 

But why exactly would you want a file which a normal user owns, and is
trying to use themselves, to have kernel security on it?

 > 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 removes any ability for me to read a file that I own without
administrator-privileged assistance.

 > And as to the ability to run GNOME on other unixes, using an NFS server for
 > VFS solves that problem. 

But requires administrative privileges.  Why should I need to be root
to decode a tar file which I own?  With the libvfs method, I don't.

And if I were to manage to mount one of these NFS-like filesystems
with the wrong privileges, so that setuid programs ran?

And what about the files I can put tarfile which aren't actually owned
by me?  When you NFS-mount such a filesystem you're making it possible 
to create files which you couldn't possibly create in practice.

 >                          Plus it has the advantage of working with ALL
 > programs on the unix. Programs like CP MV and BASH will automaticlly work.

This happens with the override library anyway, at least to some
extent.  However, I do admit that without mounting the thing as a
filesystem, you're never going to get full functionality out of these
files (particularly bash).  This *is* a kernel issue.  If you really
want a filesystem which does this, fine: go away, write one, and use
VFS underneath to do it, should you choose.  But it's not what libvfs
was written for, and it's certainly not something you can use in your
average program like mc.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]