On Thu, Jul 17, 2003 at 01:01:11PM -0400, Robert Watson wrote: +> Most system functionality that relied on procfs has been rewritten to rely +> on other mechanisms. In general, I advise against running procfs--it's +> interesting, but conceptually it's very risky. If you look at the history +> of security advisories on systems that supported procfs (FreeBSD, Linux, +> Solaris), you'll get a sense of why: procfs represents processes as files, +> and the semantics of processes and of files are very different. For +> example, with processes, there are notions of revoked access; processes +> are reused to hold several programs often running with different +> credentials. +> +> The behavior I'm aware of that currently relies on procfs and has not yet +> been adapted to use ptrace() or sysctl() are: +> +> ps -e Relies on groping around in the address space of each +> process to display environmental variables.
I've prepare patch for this:
http://garage.freebsd.pl/patches/ps-e.patch
+> truss Relies on the event model of procfs; there have been some
+> initial patches and discussion of migrating truss to ptrace() but
+> I don't think we have anything very usable yet. I'd be happy to
+> be corrected on this. :-)
Hmm, why to change this behaviour? Is there any functionality that
ktrace(1) doesn't provide? IMHO made ugly hacks just to made truss(1)
(for years procfs-dependent) working without procfs is a bad idea.
It could only display some friendly message that procfs isn't mounted
instead of:
truss: cannot open /proc/25217/mem: No such file or directory
truss: cannot open /proc/curproc/mem: No such file or directory
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp00000.pgp
Description: PGP signature
