[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

On Sat, Jan 22, 2005 at 10:08:46PM +0100, Ivan Popov wrote:
> Hi Luke,
> 
> On Sat, Jan 22, 2005 at 06:48:11PM +0000, Luke Kenneth Casson Leighton wrote:

> >  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.
> 
> sure, I meant the client side. 
 
 i understood that to be the case - sorry i didn't make that clear - i
 hope it became clearer later on from the rest of my reply.

> >  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...]
> 
> Let's see. The least common denominator for all processes' i/o
> is the corresponding host's OS' system calls.
> It means we have to intercept them (via tracing?). Then we need to hand over
> a "real" file to the process, otherwise things like mmap() stop working.
> I think it can be pretty hard to do it in a general and efficient way
> totally in user space. May be just nobody has tried hard enough?..

 i believe that what you are suggesting is to "bounce" kde file
 plugins into kernel somehow such that they are presented at
 a mount point, so that POSIX apps can get at them as if they
 were local files [yuk!  ... but actually, thinking about it,
 i think it's been done: i believe LUFS does have an example
 gnome-vfs filesystem!!! anyway...]

 ... which, i believe, may actually solve the problem, because
 LUFS (well, certainly fuse, anyway) presents file read/writes
 via a mmap interface [which i don't pretend to understand,
 i just mention it here so you can follow up on it and check
 for yourself in case my burbling swiss-cheese memory spotted
 something of use].

 anyway.

 i suggested KDE (and gnome) filesystem plugins for a completely
 different reason: to support KDE (and gnome) applications *ONLY*.

 KDE's plugin system is very simple - the operations are very
 straightforward - straighforward enough for people to write
 HTTP filesystem plugins, ftp plugins, a DOS floppy plugin,
 the-works-plugins, and so the API comprises the "lowest common
 denominator" of file operations.

 mmap isn't one of them.

 therefore, the program(s) that use(s) the KDE file plugins
 (konqueror for example) make quite simple and straightforward,
 and KDE "adapts" to the capabilities of the file plugin.

 i don't believe uids don't even come into the equation: certainly not
 for the DOS floppy plugin (which thunks down onto commands on the
 mfloppy package!)

 however, user credentials _are_ relevant: username, password etc.

 ... i do appreciate, however, that this is not exactly what
 would be considered a "perfect" solution.

 so we have applications that only use the "POSIX" system call
 access (including mmap as you say) that cannot be modified...


 the only other solution is to do LD preloading to take
 over the system calls!

 _yes_ this has been done before!!! andrew tridgell did it with
 something called "smbsh".

 it was successful: you ran "smbsh", which preloaded _open, _open64,
 __open, __open64, _read, _read64, __read, __read64, you get the idea,
 and then it could "trap" these system calls, checking whether you
 accessed a faked-up mount point (which didn't even exist on the
 filesystem) and either let it fall through to the "real" file or
 provided remote access to SMB servers otherwise.

 ... i even considered writing an rpcclient version for people
 to be able to edit Windows Registrys on remote NT systems!!!


 unfortunately, the principle was scotched by the libc6 authors
 in about 1998 when they removed some of the __<systemcallname>
 things, making them hard symbols or something, and smbsh would
 no longer work.

 since that time, there may be a workaround or it may be successful
 with a more modern version of lib6.
 
 *shrug*
 


> >  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.
> 
> Not really, though it depends on what we call a "consistent" manner.
> You can trick "ls" into displaying something feasible _without_
> relying on a global uid space. LUFS does such tricks, for example.

 yes - precisely.  ah ha! :)
 
 and that is why i was advocating that complex distributed
 filesystem clients, through which POSIX filesystem semantics
 can be granted to POSIX apps that expect them, use LUFS as
 a simpler way to develop a filesystem client.


> >  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
> 
> Christer Bernerus at Chalmers wrote the (appreciated) pam_dce module.

 hm, i wonder if it's the same one that can be referenced via the
 3rd party sw at opengroup.org/dce?


> >  CDS, and an nsswitch module, etc. which "gives" you a consistent view
> >  of your UID database across all workstations in the same "domain".
> 
> But only inside one cell. Global access in DFS is still hardly possible
> (except for anonymous read).

 that would tend to suggest that the concept of cells needs to be
 extended.
 
 or that the concept of uids needs to be deprecated in POSIX
 and replaced with SIDs (which comprise up to 5 but usually 4
 32-bit numbers representing a "domain" and are appended with
 a 32-bit RID - relative id)

 or that a "parallel" extension allowing mappings between UIDs+GIDs
 and their corresponding SIDs be allowed - in kernel.

 i realise that that all of these would mean a hell of a lot of work.

 ... but hey, some day, _someone's_ got to bite the bullet, otherwise
 everybody's going to continue bitching about this for _another_ what,
 20 years is it so far? 

 :)

 l.