Steffen Dettmer wrote:
> > In 2.4.20, the actual permission checks for ptrace() are (from
> > kernel/ptrace.c):
> >
> > if (!task->mm->dumpable && !capable(CAP_SYS_PTRACE))
> > goto bad;
>
> This is really "&&"?
Yep; cut-n-paste'd from the 2.4.20 source code. Note that a similar
situation applies to the previous set of checks as well.
> I had guessed, that if there is no
> CAP_SYS_PTRACE, there is no ptrace allowed at all, and same
> sounds logical for the "dumpable". What I'm missing?
I don't know for sure, but it would appear that the capability is
meant to override the ad-hoc mechanism. The following comment in
kernel/sys.c suggests that the capability-handling code deals with uid
manipulation issues itself.
* cap_emulate_setxuid() fixes the effective / permitted capabilities of
* a process after a call to setuid, setreuid, or setresuid.
*
* 1) When set*uiding _from_ one of {r,e,s}uid == 0 _to_ all of
* {r,e,s}uid != 0, the permitted and effective capabilities are
* cleared.
*
* 2) When set*uiding _from_ euid == 0 _to_ euid != 0, the effective
* capabilities of the process are cleared.
*
* 3) When set*uiding _from_ euid != 0 _to_ euid == 0, the effective
* capabilities are set to the permitted capabilities.
*
* fsuid is handled elsewhere. fsuid == 0 and {r,e,s}uid!= 0 should
* never happen.
--
Glynn Clements <glynn.clementsat_private>
This archive was generated by hypermail 2b30 : Mon Jan 13 2003 - 07:53:43 PST