On Thu, 2005-10-27 at 01:35 +0100, Brian Brunswick wrote: > * devices are in the filesystem namespace, socket port numbers aren't. > Whats with that? Means all sorts of things need too many privs, I > can't block things from network by uid using access permissions. > (ACLs?)
Another way to say this: One of the weaknesses of UNIX is the absence of a universally used and consistent access control model. In particular, sockets and processes are not controlled through the same mechanism as files. Mismanagement of the boundaries between these models has been a continuing source of flaws in servers, most notably sendmail, but also several others. Conclusions: 1. One bad mechanism is always better than N bad mechanisms. 2. One good mechanism is better than one bad mechanism. Unfortunately, *none* of the access control mechanisms in POSIX are good mechanism, as HRU formally proved. > * The main file API does things mostly by path name, within the > mutable namespace. More race conditions! Look at all the temporary > file and symlink bugs. I do get a process cwd, so can maybe directory > handles etc. Later we add fstat etc, getting better. This involves more problems than just race conditions. The existence of universally accessible, mutable store guarantees that any arbitrary process A can transmit information to any arbitrary process B. The transmission of information is not inherently bad. The absence of any ability to *control* the transmission of information *is* bad. > * The unified file namespace is tied all together by ".." parent acess > and by symlinks relative to the root. (And now by shared libraries for > binaries) Separating out individual directories is pretty pointless, > and chroots are a pain to use. No chance of security subdomains there. Depends on how ".." is implemented. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
