Re: O_SAFER (was: fcntl module)

[Bruno Haible]

Eric Blake wrote:
> For that matter, proposing an O_SAFER to the glibc folks might be worthwhile.

Yes, but better call it O_NONSTD. The term "safer" will confuse people who
care about security, I think, and is not specific. The term should make clear
that it won't return any STD*_FILENO.

> At which point, we have things like:
> 
> open_safer (s, f [, m]) -> open (s, f | O_SAFER [, m])
> pipe (fd)               -> pipe2 (fd, 0)
> pipe_safer (fd)         -> pipe2 (fd, O_SAFER)
> pipe2_safer (fd, flags) -> pipe2 (fd, flags | O_SAFER)
> dup (n)                 -> gl_dup (n, 0)
> dup_safer (n)           -> gl_dup (n, O_SAFER)
> dup_safer_noinherit (n) -> gl_dup (n, O_SAFER | O_CLOEXEC)

If glibc or the kernel goes into this direction, it would be cool.
Whether gnulib should define this O_SAFER, I'm not sure. We get
some problem with unistd--.h and fcntl--.h: How do we define open()
such that
   open (s, f [, m]) ::= open (s, f | O_SAFER [, m])
That becomes a bit hairy.

> With kernel support for O_SAFER, our *_safer paradigms could even be more
> efficient (no fd_safer after the fact, so fewer kernel calls and less
> temporary fd pressure).  Plus, the kernel folks have so far avoided having
> to create dup + flags

I'm not sure whether the kernel people will find an additional 'int' argument
more palatable, or an O_NONSTD flag which hardcodes a convenient value of 3.
Maybe propose both, and let them decide?

Bruno