Re: fix must_not_trace_exec() test

[Andy Lutomirski]

Olaf Dietsche wrote:

> Andrew Morton <akpm@xxxxxxxx> writes:
>
>
> Although, I'd rather not lump together unrelated tests without
> renaming must_not_trace_exec(). Btw, can someone enlighten me what
> this atomic_read() test is all about.

Oops... your fix is obviously correct.

I assumed that the test was to check if the caller is a thread, but that sounds 
odd -- wouldn't it stop being a thread after the exec anyway?  Maybe that part 
happens after compute_creds, so this prevents a race?  Although I don't see how 
it could be triggered if the thread never entered usermode before getting a new 
fs/files/sighand.

Anyone?

> Regards, Olaf.
>
> diff -urN a/security/commoncap.c b/security/commoncap.c
> --- a/security/commoncap.c	Mon Apr 12 10:38:17 2004
> +++ b/security/commoncap.c	Mon Apr 12 11:10:38 2004
> @@ -118,9 +118,9 @@
>  static inline int must_not_trace_exec (struct task_struct *p)
>  {
>  	return ((p->ptrace & PT_PTRACED) && !(p->ptrace & PT_PTRACE_CAP))
> -		|| atomic_read(&current->fs->count) > 1
> -		|| atomic_read(&current->files->count) > 1
> -		|| atomic_read(&current->sighand->count) > 1;
> +		|| atomic_read(&p->fs->count) > 1
> +		|| atomic_read(&p->files->count) > 1
> +		|| atomic_read(&p->sighand->count) > 1;
>  }
>  [...]

--Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/