> 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.
OK. The user could then script the mount to change visibility for all current processes with his uid, and new programs would inherit the visibility. It would still not work for ftp-server style programs, which are started from an independent daemon, yet after login run with the user's credentials, and hence I would expect to run with the user's "namespace". > >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. If used in conjuction with CLONE_NEWNS it would have all the needed flexibility. > 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. Yes, that is what I meant. > We've been straining against the limitations of user/group/other for > decades. Sophisticated systems don't even use them for file permissions. 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_. Miklos - 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
