Re: fexecve, round 2

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

On Mon, Nov 19, 2012 at 08:08:58AM +0000, Emmanuel Dreyfus wrote:
> On Mon, Nov 19, 2012 at 05:23:07AM +0000, David Holland wrote:
> > 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.
> 
> It seems consistent with the check at system call time that you proposed 
> to forbid. Here is how I understand it for an openat/mkdirat sequence:
> - openat() without O_SEARCH, get a search check at mkdirat() time
> - openat() with O_SEARCH, mkdirat() performs no search check.
> 
> and for openat/fexecve:
> - openat() without O_SEXEC, get a execute check at fexecve() time
> - openat() with O_EXEC, fexecve() performs no exec check.
> 
> If you have r-x permission, you open with O_RDONLY and you do not need
> O_SEARCH/O_EXEC. 
> 
> If you have --x permission, you open with O_SEARCH/O_EXEC

I think the standard implied that O_EXEC gave you read and execute
permissions. So you can't use it to open files that are --x.

I haven't seen a quote for O_SEARCH.
Without the xxxat() functions the read/write state of directory fds
(as opposed to that of the directory itself) has never mattered.
O_SEARCH might be there to allow you to open "." when you don't
have read (or write) access to it.

For openat() it is plausible that write access to the directory fd
might be needed as well as write access to the underlying directory
in order to create files.

        David

-- 
David Laight: david%l8s.co.uk@localhost