Date: Sun, 18 Jan 1998 07:53:06 -0800 From: David Greenman <dg@root.com> To: John Polstra <jdp@polstra.com> Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG Subject: Re: dladdr hax Message-ID: <199801181553.HAA24836@implode.root.com> In-Reply-To: Your message of "Sat, 17 Jan 1998 18:48:06 PST." <199801180248.SAA09258@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> we save the path -- the most intuitive place is the proc >> structure. > >I don't purport to speak for David Greenman, but I would guess that >anything like this that slowed down every exec might not make him >too happy. An acceptable solution should have virtually zero impact >except on processes that actually call dladdr. I think that's >probably do-able. One idea (not well thought through, so it might >not work) would be to have the kernel save pointers to the vnode of >the executable and the vnode of the directory that contained it at >exec time. I think that from those two things it should be possible >to compute a full pathname later on. Of course, it would fail if >somebody (re)moved the executable file after it was already running, >but so would just about any approach. Yes, I would be most displeased with a kludge that added 1KB (MAXPATHLEN) to our struct proc as well as increased the overhead of doing the exec. Your suggestion is a good one and in fact we already save the vp of the image being execed; see p->p_textvp. If the directory vnode is also stored, then one could do the equivilent of 'getcwd' on that directory and yield the full path to the file. There may be directory reference count complications, however - you'd have to hold a reference to the directory vnode while the image was running, and this could be evil. Needs more thought. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801181553.HAA24836>