[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fexecve, round 2
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 Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |