On 10 Nov 2000, Nathan J. Williams wrote:

> > Thoughts?
> 
> ``Yuck''.
> 
> 1) This feels like it's solving the wrong problem. If there are issues
>    with opening non-regular files that have side-effects on reading,
>    then there will be issues opening regular files that the user
>    shouldn't access, too.

That's not the problem this patch is trying to address.

This patch is very specifically attempting to permit userland code,
specifically library routines which open paths passed in via user-settable
envirnment strings, to make sure that open() doesn't open devices with
on-open behaviors.

You are right that this patch alone is not the be-all & end-all of
security for these environment varialbes.

There is a companion patch made by Kimmo Suominen, which I don't think has
been floated in public yet, which makes the code which uses HOSTALIASES,
when called from a set-id program, open the path both with the current and
the saved IDs. That code will ensure that the user can open the file (both
opens have to succeed) and that there haven't been redirection attacks
inbetween (check mount point & inode #).

> 2) Side effects on open are gross. What examples exist besides the
>    tapes? 

Not many. The only other one I can see is fifos. Once both sides have
opened, when one closes the other gets closed too.

But I think tape drives are enough.

> 3) Increases unportability and won't be reliably used by third-party
>    code.

If we required portability exclusivly, there are a lot of thing we
wouldn't do. :-)

Also, the main customer for this that I see will be the fopen(,"rf") code
path. i.e. things in our libraries.

What does it take to get things in POSIX?

> 4) Lack of symmetry. If there's an O_REG_FILE, there should be an
>    O_CHAR_DEVICE, an O_BLOCK_DEVICE, an O_DIRECTORY, ..... and this
>    way of handling the issue quickly becomes unwieldly.

I can live w/o the symetry. I can't think if customers for the others. And
we have opendir() for O_DIRECTORY..

> 5) Personally, it seems like a lot of trouble and cruft for a feature
>    that I've never used, or even heard of before its security issues 
>    came up :)

$HOSTALISES? It's really nice. And it really frustrated many of us
(including me) when set-id programs lost its use.

Also, while the patch Kimmo sent was just for HOSTALIASES, I think we need
to make a general librarly routine which will do the double-open dance. I
expect other library routines will want it too. Bill Sommerfeld mentioned
catgets/gettext() as one example.

Take care,

Bill