>It would still not work for ftp-server style programs, True. Users might want the mounts to show up to an ftp or not, and this handles only "not."
>If used in conjuction with CLONE_NEWNS it would have all the needed >flexibility. I don't see how. What if my policy is that processes with a certain process name (command) see the mount? What if my policy is that users in a certain filesystem ACL can see it? That's the kind of flexibility you can't get if the policy is set up via the mount() system call. >But the non-sophisticated case is by far the most abundant. And for >that the traditional UNIX permission modell is not only good enough, >it is in fact _better_ than any sophisticated access control mechanism >because of it's _simplicity_. Absolutely. And that's why I speak of flexibility. Let the simple users have their simple U-G-0 and the more creative ones do something more complex. I'm not opposed, by the way, to an implementation that just does U-G-O (or even just U) if it's done in a way amenable to future extension. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
