Hello, Al.
What would you suggest if FMODE_EXEC is not the right choice?
On 2019/01/22 9:51, Kees Cook wrote:
> On Tue, Jan 22, 2019 at 10:18 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>> We are *NOT* going to use current->in_execve to propagate that information.
>> Come up with a cleaner solution, if you care, but this one is a non-starter.
>> Too ugly to live. Sorry.
>
> What would you suggest for a cleaner indication of being in an execve?
>
On 2019/02/12 14:26, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
>> Andrew Morton wrote:
>>>> --- a/fs/open.c
>>>> +++ b/fs/open.c
>>>> @@ -733,6 +733,12 @@ static int do_dentry_open(struct file *f,
>>>> return 0;
>>>> }
>>>>
>>>> + /* Any file opened for execve()/uselib() has to be a regular file. */
>>>> + if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) {
>>>> + error = -EACCES;
>>>> + goto cleanup_file;
>>>> + }
>>>> +
>>>> if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) {
>>>> error = get_write_access(inode);
>>>> if (unlikely(error))
>>>
>>> This change sounds legitimate for various other reasons, but it's a
>>> concern that this locking error occurred in the first place. There's a
>>> problem somewhere (probably the pipe code) which may bite us in other
>>> situations, even with this workaround in place.
>>>
>>>
>>
>> This error seems to be introduced in 2.6.39-rc1 by commit a9712bc12c40c172
>> ("deal with races in /proc/*/{syscall,stack,personality}"). Thus, I don't
>> think that this patch will bite us in other situations.
>> Al, how do you want to handle this?
>>
>
> According to bisection, commit 8924feff66f35fe2 ("splice: lift pipe_lock out of splice_to_pipe()")
> added in 4.9-rc1 is the trigger of this deadlock. Thus, the fix needs to go to 4.9+.
