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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
