On Mon, Nov 19, 2012 at 05:23:07AM +0000, David Holland wrote: > 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.
Does fchmod() itself have any issues? If I open a file that doesn't have write permissions, I can use fchmod() to add write permissions. My open fd won't magically gain write access, but maybe I can open it again via /dev/fd (possibly after linking the inode back into the filesystem) and gain the extra permissions. Clearly I would need to be the owner, but with chroots that shouldn't be enough if the file might actually be outsde the chroot. David -- David Laight: da...@l8s.co.uk