>How would you request to make the mountpoint visible from _any_ >program. It's not acceptable to expect every program to include a >menu, command, etc. to be able to modify the visibility of >mountpoints.
OK, I overlooked the problem of having to add commands to the shell and everything else. While there's plenty of precedent for this style (current directory, ulimits, umask), I wouldn't like to extend it, even to adding a command to Bash. But it could follow the 'nice' and 'renice' model. >Would it not be better if you could specify the visibility policy when >mounting? Something simple like the user-group-other permission >model would do nicely. That would also have the advantage of being >bound to the mountpoint, not the process. I just don't think that gives you enough policy flexibility. If processes can control visibility on a per-process basis independent from the mount action, they can use a much greater variety of policy, and do it in user space. As for user-group-other, let me first point out that this whole namespace discussion started when a design based on actual file permission bits, but not a true implementation of Unix security (root didn't get carte blanche) was found unpalatable by some. So as you say, it would be something _like_ the permission model, not a part of it. We've been straining against the limitations of user/group/other for decades. Sophisticated systems don't even use them for file permissions. So I hesitate to tie anything else to them. -- 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
