Re: Which 90% of POSIX /is/ good then?

[Jonathan S. Shapiro]

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