[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

On Sat, Jan 22, 2005 at 05:56:53PM +0100, Ivan Popov wrote:
> Thanks Tom,
> 
> now I understand your point better.
> 
> On Fri, Jan 21, 2005 at 04:56:16PM -0500, Tom Keiser wrote:
> > cache manager:
> > - responsible for storage of data and metadata
> > - responsible for cache replacement strategy
> > - API for interaction with implementation of VFS interface
> > - API for access by RPC endpoint for things like cache invalidation
> 
> On Coda list we have had a small discussion about splitting out cache space
> reclaimation from the (user space) cache manager.
> It seems feasible, and possible in a portable way.
> I doubt though that a similar approach would work for AFS or DFS as their
> cache is a lot more complicated.
> 
> > credential manager:
> > - example would be the linux 2.6 keyring implementation
> 
> <skippable>
> I think all that keyring business is a try to "work around" a basic
> Unix principle - that credentials are tied to an UID, that's it.

 that's only relevant _if_ you are accessing files - and if you are
 accessing them via the POSIX subsystem.

 if you run the entire file server out of, say, a database (e.g. like
 Apache Subversion / WebDav) and also the security and the concept of
 the user is managed independently of the POSIX / Unix idea of security,
 who _gives_ a monkeys about UIDs - they're completely and utterly
 irrelevant.

 which is why it's so much simpler, cleaner and just not so much of a
 pig if everything client-side is done in userspace [KDE / Gnome
 filesystem plugin...]


 where UIDs become relevant is when you start messing about with trying
 to present files from one Unix filesystem in a consistent manner on
 another Unix workstation.

 so then, all parties - all file servers and all workstations, and all
 processes accessing the same files - need to have the same view of the
 world: a distributed UID database.

 DFS has all that - from what i can gather - via CDS - cell directory
 services, and someone has made an effort to write a PAM plugin for DCE
 CDS, and an nsswitch module, etc. which "gives" you a consistent view
 of your UID database across all workstations in the same "domain".

 An attempt was made to do the same thing with Samba, with a program
 called "winbindd", but unfortunately, the people who were in control of
 writing it did not take into account the need to "distribute" the UIDs
 consistently across multiple unix workstations.
 
 consequently, with winbindd, you can join Unix workstations to
 an NT Domain, you can run pam_winbindd and nsswitch_winbindd,
 so you have the same "names" but the uids could differ, depending
 on who logs in first!

 actually it wouldn't be difficult to distribute the sid<->uid/gid
 entries, all you'd need to do was have one central server which
 controls lookups for all workstations.


> It can work as a conveniency feature, but it just hides the fact -
> if you need separate security domains for different processes, they
> have to be of different UIDs, otherwise the system cannot protect them
> from each other (except possibly for special cases like jailed/chrooted).

 and selinux, which "tracks" processes in a predefined way [making sure
 that they only make certain system calls]

 but that's a different story.

> The rights management in a Unix-like system is tied to UIDs, not to PAGs
> or alike. We'd have to redesign all syscalls to be able to securely use PAGs.
> </skippable>

 ... or you have a central lookup table service which your
 nss_myweirdservice is told about, looks stuff up in.

 ... it's not difficult - just necessary to get your head round a few
 weird ideas involving lots of machines rather than just one.

 anyway - i _really_ wish Unix had VMS/NT Security Descriptors
 not this stupid single 32-bit rubbish, it _really_ would make
 life a lot easier.



> > implementation of VFS interface:
> > - very os-specific stuff
> > - probably in-kernel unless something like LUFS takes off
> 
> LUFS seems to mean "Linux Userland File System" which does not promise a lot
> about portability?

 solution for linux is a solution for linux: i presume that there exist
 userspace filesystem drivers for other OSes?

 and even a solution for linux requires that the uids be
 consistent and possible to look up (see above) but contacting
 a remote service to find out your uid is an _awful_ lot easier
 to do in userspace than it is in kernel-land.

 the thought of doing that kind of thing in-kernel just makes
 me wanna puke - it's just _so_ inappropriate!

 l.