> > I have a little project to imlement a "userloop" filesystem, which > > works just like "mount -o loop", but you don't need root privs. This > > is really simple to do with FUSE and UML. > > That would be a nice way to implement those rarely used old > filesystems that aren't really needed in the kernel source tree any > more, but which it would be nice to have access to as legacy > filesystem formats. > > In other words, migrating old legacy filesystems out of the kernel > tree, into FUSE.
Not much migration would be needed other than deleting from the current kernel. As long as the lagacy filesystem exists in a kernel that has UML support it should just work. > > I don't think that it's far feched, that in certain situations the > > user _does_ have the right (and usefulness) to do otherwise privileged > > filesystem operations. > > It's really a matter of philosophy, as to whether the results of > stat() are just handy information for the user, or are always defined > to mean what you can/can't do with a file. Yes, this is the very heart of the conflict between my and your (Christoph's, etc) view. I argue for more flexibilty, i.e. less policy in kernel, which is a good thing generally. As long as it's secure, what is the problem with it? If users are confused, then they will chose the strict mode. If somebody would like to see more information in the filesystem, they use the relaxed mode. The key here is security IMO. So if you find a security problem with the relaxed mode (together with "hiding") then I bow my head. Otherwise who cares if it confuses applications (haven't met any) or users. It doensn't matter. If it confuses anything or anyone, the filesystem writer can fix it. > Local-ssh-into-UML makes more sense for this in some ways, because the > uids/gids inside your tgz files or foreign loop filesystems are not > related to the space of uids/gids of the host system. Ssh into UML is awkward, because you don't necessary have all the tools installed, have networking, etc. And in UML the uid/gid won't make any more sense either. > Yet, the results from stat() don't distinguish the number spaces, > and "ls" doesn't map the numbers to names properly in the wrong > space. Well you can use "ls -n". It's up to the tools to present the information you want in the way you want it. If a tool can't do that, tough, but you are not worse off than if the information is not available _at_all_. Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
