> >The same happened to me. The problem is that strace accesses the tracee's
> >memory through /proc/<pid>/mem but as of 1.3.96 any read from processes
> >different from the one which owns the memory fail with EACCES.
> >Here is the relevant piece of code from linux/fs/proc/mem.c in function
> >mem_read:
(clip)
> >
> >Can anyone out there tell me if there is any reason for this new behavior?
>
> This looks like an overly-conservative patch for the /proc/<pid>/mem
> security hole involving setuid programs. The kernel should really return
> EACCESS only if the process we are trying to read is setuid.
>
> (Got to start reading those patches more carefully... :-))
>
> -- Aaron Ucko (ucko@vax1.rockhurst.edu; finger for PGP public key) | httyp!
> "That's right," he said. "We're philosophers. We think, therefore we am."
> -- Terry Pratchett, _Small Gods_ | Geek Code 3.1 [for explanation, finger
> hayden@mankato.msus.edu]: GCS/M/S/C d- s: a18 C++(+++)>++++ UL++>++++ P++
> L++>+++++ E- W(-) N++(+) o+ K- w--- O M@ V-(--) PS++(+++) PE- Y(+) PGP(+) t(+)
> !5 X-- R(-) tv-@ b++(+++) DI+ !D-- G++(+++) e->+++++(*) h!>+ r-(--)>+++ y?
>From what I caught of the discussion, you can start watching the process's
memory, then have the process 'exec' something suid root, and read straight
through the suid root memory.
In other words, you can get to suid root memory through the /proc/pid/mem of
a process that runs a suid root program, provided you trace the memory at
the correct time.
__kmb203@psu.edu_____________________________Debian/GNU__Linux__1.3.77___
The greatest dangers to liberty lurk in insidious encroachment by men
of zeal, well-meaning but without understanding.
-- Justice Louis D. Brandeis