On Sun, Nov 18, 2012 at 06:51:51PM +0000, David Holland wrote: > > > This appears to contradict either the description of O_EXEC in the > > > standard, or the standard's rationale for adding fexecve(). The > > > standard says O_EXEC causes the file to be open for execution "only". > > > > > > In other words, O_EXEC means you can't read nor write the file. Now > > > the rationale for fexecve() doesn't hold, since you cannot read from > > > the fd, then exec from it without a reopen. > > > > > > Further, requiring O_EXEC would seem to directly contravene the > > > standard's language about fexecve()'s behavior. > > > > The standard is clearly wrong on a number of points and doesn't match > > the historical design and behavior of Unix. Let's either implement > > something correct, or not implement it at all. > > Also it seems that the specification of O_SEARCH (and I think the > implementation we just got, too) is flawed in the same way - it is > performing access checks at use time instead of at open time.
So, for the record, I think none of these flags should be added unless they behave the same way opening for write does -- the flag cannot be set except at open time, and only if the opening process has permission to make the selected type of access; once opened the resulting file handle functions as a capability that allows the selected type of access. Anything else creates horrible inconsistencies and violates the principle of least surprise, both of which are not acceptable as part of the access control system. Also, it obviously needs to be possible to open files O_RDONLY|O_EXEC for O_EXEC to be useful, and open directories O_RDONLY|O_SEARCH, and so forth. I don't know what POSIX may have been thinking when they tried to forbid this but forbidding it makes about as much sense as forbidding O_RDWR, maybe less. Someone needs to sit down and figure out what restrictions need to be applied to fd passing to make this safe, both in general and in connection with chroot. One point riastradh@ raised is that if you get a fd for a directory outside your current chroot, you shouldn't be able to use it to openat() or with any of the *at() calls. There is currently no mechanism in place to enforce this. I have a feeling that what we want may be not a restriction on fd-passing sockets or a restriction on file handles, but a restriction on chroots. Also there was a thread back in February titled O_NOACCESS that everyone interested in this stuff should review. > (Also the implementation we just got seems to be missing any access > check at open time -- this seems entirely wrong.) It turns out to be unexploitable but it's definitely wrong in several ways (unrelated to whether its semantics are poorly chosen); I have asked for it to be reverted. -- David A. Holland dholl...@netbsd.org