Coda File System

Re: CODA kernel module limitations...

From: Roland Mainz <>
Date: Thu, 19 Oct 2000 05:54:42 +0200
Jan Harkes wrote:

> > > - Security is difficult.
> >
> > Again... the NFS-is-insecure-mythos... seems it will never die. Starting
> > with NFSv3 SecureRPC, Kerberos4/5 or GSS-API may be used for
> > authentification, too.
> Don't worry about the insecure-mythos. Security is a never ending story,
> even after you get a secure transport layer.
> How do you want to tie a user identity and access permissions to a page
> that is shared between multiple mappings (by different `users') of a
> file when it has to get paged in?

What about using something sort of Copy-on-write - users can share a
file rw - read from same source file but write to different copies ?

> Basically once you hit the lower layers of the VFS or are being called
> out of the VM, it is very difficult to impossible to figure out who the
> `authenticated user' is supposed to be. In most cases it doesn't matter
> except for cases where access permission for data is being taken away.
> And a stateless world makes this hard. Luckily for us, it is perfectly
> valid for Coda to give the user the stale version when he still had
> access.



Assuming I'd like to add new upcalls for read (CODA_READ) and write
(CODA_WRITE). How to handle the transport/allocation/handling of buffers
(which may have any size (1byte - >1Pb(PetaByte)) ? Ideas ?


Anyone interested in kernel module binaries for both 32bit and 64bit
Solaris 7 SPARC ?



  __ .  . __
 (o.\ \/ /.o)
  /O /==\ O\  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
 (;O/ \/ \O;) TEL +49 641 99-13193 FAX +49 641 99-41359
Received on 2000-10-18 23:55:52