On 6 September 2012 13:25, Martin Decky <[email protected]> wrote: > Hello Jiri, > > here are a few of my comments to your VFS proposal. In general, I consider > your proposal reasonable and interesting. I am really looking forward to > some initial prototype. >
I'm really glad you think so. >> 1. A task can have its own private “view” of all the resources it accesses >> via VFS. >> b. Hurd and Plan9 made some steps towards creating customized namespaces >> for processes, though the basic usage pattern matches that of legacy >> systems. > > [...] > > Therefore the crucial point here is not only to implement the namespace > mechanisms, but more importantly to design the usage patterns and policies > for such mechanisms and wrap them in convenient run-time services. > Indeed. My main motivation for this work is my general idea of how I want it to work from the user's perspective, though I haven't written much about that anywhere. >> My personal experience is that per-file permissions are non-obvious, easy >> to get wrong and also a complete mess when sharing files among systems with >> different sets of users. Protection based on location accessibility is >> natural for humans (if you want some thing inaccessible, you put it in an >> inaccessible place; putting a sticker with your name on it won’t stop >> thieves, thick steel door usually will). > > > This is also an interesting idea, related to the capability-based systems > (as already mentioned in this thread). > Guess I really need to read up on those. Do you know of any introductory papers on the subject? > Again, my concern here would be very practical: Traditional i-node > permissions make it easy to persistently store the complete effective > permission set of a file system (and recreate it in memory when accessing > the file system). The problem of sharing files among systems can be solved > by not using local identifiers of subjects (e.g. users), but by using > globally unique identifiers. > My concern here is also practical. There are many cases where the traditional concept of files having inherent owner and permissions is really clumsy. I find it really entertaining to pull a public source code repository and having to reset permissions on the whole tree, because half the source files have executable bit set for no imaginable reason (which may and may not be a bug in the VCS, but that's not really the point). Especially so since I have absolutely no need for any individual permissions in my entire home directory, except for a single directory that is shared to others. Thus my intention is to figure out whether a more coarse-grained permission system (based on conventional structure of the filesystem rather than individual file ownership) would be sufficient for most cases, and how to deal with the rest. > I am not saying that the problem of persistent storage and recreation of the > effective permission set cannot be solved in capability-based systems. I am > just saying that you should perhaps elaborate on it, too, because the > solution needs to be designed properly (both on the level of mechanisms and > on the level of policies). > Yes, you're definitely right about that. >> Their addressing uses a notation similar to that of Plan9 (where it only >> covers device namespaces); paths start with the ‘#’ symbol > > > I know that you striked-through this part, but I would still like to propose > an alternative. My idea of how one might address the imported trees is based > on URLs. I.e. an imported tree can be addressed using an URL scheme in a > form of: > [...] It's striked-through because I figured it would be simpler if you could simply traverse the directory structure through file nodes alone, without any absolute paths. E.g. file_node *vfs_get_child(file_node *dir, char *relative_name); or something like that. Then no new addressing scheme is necessary, if the mount operation gives you a node reference. I like your idea though. -- Jirka Z. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
