> While FUSE doesn't handle it directly, doesn't it have to punt it to > its network file systems, how to the sshfs and what not handle this > sort of mapping?
Sshfs handles it by not handling it. In this case it is neither possible, nor needed to be able to correctly map the id space. Yes, it may confuse the user. It may even confuse the kernel for sticky directories(*). But basically it just works, and is very simple. > Not really a criticism, just curious. This doesn't so much relate > to FUSE, but I've been wrestling with what to do about this chunk of > (mapping) code -- it seems like it might be a good idea to have some > common code shared amongst the networked file systems to handle this > sort of thing. The NFS idmapd service seems overcomplicated, but > something like that in the common code could provide the same level > of service. What do folks think? Should someone (me?) take a whack > at a common id mapping service for the kernel (or just extract > idmapd from NFS) -- or is this something better implemented > filesystem-to-filesystem? If more than one filesystem would use it, it would make sense to abstract it out. FUSE doesn't need it since it can happily do the mapping in userspace. Miklos (*) I think the correct behavior would be if checking sticky permissions could also be delegated to the filesystem, like checking normal permissions can be. - 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/
