Coda File System

Re: Mac OS X Client status

From: <u-codalist-s7mc_at_aetey.se>
Date: Sun, 18 Dec 2011 09:03:23 +0100
Hello Greg,

On Sat, Dec 17, 2011 at 09:49:21AM -0500, Greg Troxel wrote:
> I have long ranted that there should be a FUSE version of coda.

+1

(On the other side I am happy having the good performance on Linux and
would love to be able to rely on Coda on *BSD. The work needed to fix the
module there is most probably much less than creating a FUSE version)

>  Not sure if that is what "userland" means.

Userland-only Coda implies emphasis on -only. It does not need any fs-
specific support from the kernel nor any privileged system calls like
mount(). Thus it does not need any superuser rights, any user on
any computer can run it. Separate caches for separate users ensure also
correct access control semantics, both while connected and disconnected.
Performance is about the same as the traditional kernel-based.

Alas, it looks like it can not work properly with systems like recent
MacOSX where some functions of the OS/UI are done via non-standard
interfaces to processes which are run with superuser privileges. To
"teach such processes about Coda" would need as much privileges
as inserting a kernel extension and doing mount().

I am not sure whether FUSE would properly solve this, basically uid 0 is
assumed to have the power over all users' data, even on networked file
systems - which means it (ab)uses the corresponding credentials. IMVHO it
is a bad design - even if it is impossible to prevent root from stealing
credentials, it is too close for comfort when it _always_ does this.

(MacOSX is targeted at single-user installations where the only user
and Apple itself share the power over all the data. Apparently Apple
wants to have the power over all of the user's data, not necessarily
residing on the same computer as MacOSX :)

Regards,
Rune
Received on 2011-12-18 03:04:44
Binary file ./codalist-2011/9175.html matches