On Sat, 26 Feb 2000, Peter T. Breuer wrote:
>> <humor>
>> Would I have to run mklost+found on /proc? Would it be a 12k directory
>> like every other lost+found?
>
>I think it might have to be :-). Well, how many zombies can _you_ spawn?
I didn't name the machine "nightofthelivingdead" for nothing :-)
>> Might I suggest a /proc/0/... tree of process information? (task[0] is
>> the kernel after all.) It would help reduce the clutter in /proc. It
>
>Not bad (isn't it the task that isn't?). But using the inodes as
Well, if task[0] exits, "all hell breaks loose"...
>numbers and the names as names might make more sense! /proc/kernel,
>/proc/init, etc... (and there is nothing wrong with /proc/lost+found,
>except that it had better have a crazy inode number, as it can't ever
>collect itself).
How about 0?
>What does this clutter matter, btw? I think the valid point you really
The readdir() walk of /proc for process information. A little organization
isn't a bad thing. (Or do you prefer the old flat file system of older MacOS)
>have concerns the chroot'ed root who can mount /proc and therefore get
>at all processes .. as though he couldn't already mount the disk
>partitions and do enough damage (and telnet to his own copy of telnetd
>...).
chroot() is prevent programs from messing things up accidentally. For a
targeted attack, once root access is attained, there's not much one cannot
do. And you cannot re-mount an already mounted partition. (I just tried
with proc unmounted and mtab erased.) [I think we will all agree there's
no stopping root from doing something.]
--Ricky
-
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:15 EST