[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090507092757.GA32526@elte.hu>
Date: Thu, 7 May 2009 11:27:57 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Roland McGrath <roland@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Chris Wright <chrisw@...s-sol.org>,
linux-kernel@...r.kernel.org, Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [patch] security: rename ptrace_may_access =>
ptrace_access_check
* Oleg Nesterov <oleg@...hat.com> wrote:
> On 05/07, Ingo Molnar wrote:
> >
> > * Ingo Molnar <mingo@...e.hu> wrote:
> > Subject: security: rename ptrace_may_access => ptrace_access_check
> > From: Ingo Molnar <mingo@...e.hu>
> >
> > The ->ptrace_may_access() methods are named confusingly - the real
> > ptrace_may_access() returns a bool, while these security checks have
> > a retval convention.
> >
> > Rename it to ptrace_access_check, to reduce the confusion factor.
>
> Great. Now we can rename (and fix the callers of) ptrace.c:ptrace_may_access()
> accordingly.
>
> But,
>
> > -static inline int security_ptrace_may_access(struct task_struct *child,
> > +static inline int security_ptrace_access_check(struct task_struct *child,
> > unsigned int mode)
>
> You seem to forgot to update the callers of this helper.
Did i mention that it's completely untested :) Yeah, i'd suggest to
push this naming down the whole ptrace_may_access landscape, and
eliminate the bool. In two separate patches: first the rename, then
the bool-elimination (which is more dangerous).
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists