Re: fexecve, round 2

[David Laight <david%l8s.co.uk@localhost>]

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: david%l8s.co.uk@localhost