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

[Brian Brunswick]

On 27/10/05, Alfred M. Szmidt <address@hidden> wrote:
>    * pids are broken. They aren't persistent handles, like fds, so
>    hello race conditions on anything using them.
>
> You cannot get away from race conditions, nor should pids be persitent
> in a non-persitent system.  In other words, PID's aren't broken.

By persistent, I mean on the the short term. You have absolutely /no
guarantee/ that the process you send a signal to is actually the same
one you just collected the pid for. They get re-used quite fast. They
should be like file handles instead, always referring to the same
object.

>
>    * devices are in the filesystem namespace, socket port numbers
>    aren't.
>
> POSIX doesn't mandate that devices must be in the filesystem
> namespace.
>
>    * 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.
>
> Race conditions cannot be fixed, no matter what kind of a API you
> implement.

They can be discouraged. Any program which uses the same path twice in
different calls is potentially broken. There should be only one
function to map a path name to an fd, and all others should work on
fds. This includes for directories. That would increase performance
too.

>
>    * uids are an amazingly coarse security measure. They are all or
>    nothing. And every process gets the whole system call array to use:
>    network, interprocess signals, etc. No way to create subsets.
>
> This has nothing to do with POSIX, you are free to imlpement subsets,
> this was done in the Hurd.

Plan9.

>
>    * 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.
>
> This isn't a argument against what you call a unified file namespace,
> it is a argument against: badly written programs and chroot's.

It means that subdirectories aren't useful from the security
standpoint. And chroots need unreasonable amounts of stuff to be put
into them. If security is hard to get right, people will get it wrong.
The system should make security easy to do. (Why on earth need to be
root to set up a chroot?)

It should be easy to restrict programs to accessing limited sets of files.

Eg, look at the shell, and the use of stdin/stdout/stderr redirection.
The same mechanism should be used for all file access, and the shell
being the only thing that opens file handles. Rarely, I might pass a
directory handle in to a program to give it access to all the
contents.
Effectively, file capabilities.This could all have been done 20 years ago.

I want to trust only a few programs to have full access to all my home
dir. The fewer I have to trust, the better. At home, I run my web
browser in a separate uid for just this reason, but that needs root to
set up, and still suffers from X session keyboard spying issues.

>
>    * terminal subsystem - stuck in the days of serial access. What
>    happened to graphics, multimedia? Oh yes, we've got X. Its ok, but
>    somehow lacking in quite a lot. Where's my network transparent
>    sound after 20 years?
>
> The terminal subsystem in POSIX is actually quite fine, it doesn't
> prohibit you from implementing any of what you suggest.  Once again
> this is not a argument with how POSIX does something, but a argument
> what is _missing_ in POSIX (and one can argue if such things should be
> in POSIX at all).

Indeed. Why have all that complex terminal behaviour?

>
>    * File access API. Assumes most files are mutable. (clue: this
>    turns out to be wrong!) Ignores multiple versions. Destroys
>    transactional semantics by making files appear in filesystem on
>    open, instead of on close. Hello access to half-completed files!
>    Oh, wow, we do a get a transactional rename. Wot no metadata?
>
> All of these has nothing to do with POSIX once again, you are free to
> implement a versioning file-system, add metadata etc, and it won't
> make the system a non-POSIX system.

It will if I want to change the way files are created and used to be
transactional, when the POSIX semantics mandate the opposite. Most
files should be created read only, and immutable. Oh dear, POSIX
programs don't tell the system which ones need to be different from
that, meaning I have to have big overheads in file systems to support
updating all files, all for the ake of the tiny  percentage of files
which actually are updated.

>
>    * fork: oh dear, it leaves all the fds open, signals enabled,
>    sessions wrong, uids gids etc. Its rarely what we actually
>    want. Most things just (forget to) close lots of things and exec
>    immediately.
>
> So you blame incompetence instead of attacking the real faults with
> fork/exec.

No, I'm attacking those faults - the design of fork/exec encourages
that incompetence. Unless you make security the default, it won't
happen. POSIX mandates the opposite...

>
>    * device model. We've got character and block devices. How much of
>    their behaviour is standardised? What about standards for other
>    sorts?  Hello ioctl hell!
>
> ioctl isn't meant as a general way to access all types of things; it
> is meant as a cheap way to access a specific feature of the device
> (like rewinding a tape, or ejecting a CD).  If you don't know what a
> block/char. special file is, then you should read the standard.

There are lots more types of devices than block/char. What about
standards for them?
What about a way to query what ioctls a device understands, what sort
is is. What about standardised sharing semantics?

>
>    * Shell process control. Its stuck in the tty age. screen is your
>    friend.... Except when ptys go bad. Can you say security nightmare?
>
> No, I can't.  Can you say: Nothing to do with POSIX?
>
>    * pipes. raw character streams. all that richly formatted data
>    squashed into it. Look at the hassle of making find | xargs grep
>    work with arbitrarily named files.
>
> Once again not a problem with POSIX, blame the implementation.  For
> the record, I have never experienced problems with find+grep with
> arbitrarily named files (this includes files with weirdo chars that I
> can't input without resorting to octal codes).
>
> What you seem to not understand about POSIX is that it is a middle
> ground for writting portable programs, programs that will run on
> various POSIX systems.
>

To me its a ground for making writing secure programs hard. There are
so many parts that could have been done better....

For evidence, look at all the /totally stupid/ security holes we keep
getting. The same bugs coming up over and over in different programs.
The system API design should be fixing that.

I just want a chance to hear about more interesting non-trivial
security holes instead:-)

--
address@hidden