From 8074856056118e60d276251ecf2619b6a03e4d47 Mon Sep 17 00:00:00 2001 From: sef Date: Mon, 8 Nov 1999 05:13:54 +0000 Subject: Explain why Warner is right, and I am wrong, in the removing of the file object. Also explain some possible directions to re-implement it -- I'm not sure it should be, given the minimal application use. (Other than having the debugger automatically access the symbols for a process, the main use I'd found was with some minor accounting ability, but _that_ depends on it being in the filesystem space; an ioctl access method would be useless in that case.) This is a code-less change; only a comment has been added. --- sys/miscfs/procfs/procfs_mem.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'sys/miscfs') diff --git a/sys/miscfs/procfs/procfs_mem.c b/sys/miscfs/procfs/procfs_mem.c index 43652f1..df97979 100644 --- a/sys/miscfs/procfs/procfs_mem.c +++ b/sys/miscfs/procfs/procfs_mem.c @@ -314,6 +314,20 @@ procfs_domem(curp, p, pfs, uio) * wait() all maintain the p_textvp field in the * process proc structure which contains a held * reference to the exec'ed vnode. + * + * XXX - Currently, this is not not used, as the + * /proc/pid/file object exposes an information leak + * that shouldn't happen. Using a mount option would + * make it configurable on a per-system (or, at least, + * per-mount) basis; however, that's not really best. + * The best way to do it, I think, would be as an + * ioctl; this would restrict it to the uid running + * program, or root, which seems a reasonable compromise. + * However, the number of applications for this is + * minimal, if it can't be seen in the filesytem space, + * and doint it as an ioctl makes it somewhat less + * useful due to the, well, inelegance. + * */ struct vnode * procfs_findtextvp(p) -- cgit v1.1