>
> > There's too much stuff in /proc. Much of it required for programs you
> > would never expect would want to see what is historically process data.
>
> In what way is this bad? Can you have too much information available?
> Maybe ...
I think that better resolution for availability of /proc information would
be a good thing.
>
> > 2 - /proc is the only point of reference to most of what's in it. Disable
> > procfs and practically nothing works.
>
> Well, only ps fails that I know of!
No. There's much more programs, eg. Xservers accessing /proc/pci
depmod accessing /proc/modules, etc... How they could work if you want to
disable process information (/proc/PID/*) ?
> > 3 - dependance on procfs (see #2) makes secured binary environments (i.e.
> > chroot()ed areas) difficult and impossible.
>
> Procfs has races and security problems. They should be addressed.
And it would be a good thing to be able to disable insecure parts
before fixing security problems.
Andrzej
-- ======================================================================= Andrzej M. Krzysztofowicz ankry@mif.pg.gda.pl phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:09 EST