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
