Date: Tue, 04 Sep 2012 19:46:23 -0400 From: Sam Varshavchik <mrsam@courier-mta.com> To: freebsd-hackers@freebsd.org Subject: Re: What happened to my /proc/curproc/file? Message-ID: <cone.1346802383.225884.23058.1000@monster.email-scan.com> References: <cone.1346723177.448775.23058.1000@monster.email-scan.com> <20120904101429.GV33100@deviant.kiev.zoral.com.ua> <cone.1346757042.638408.23058.1000@monster.email-scan.com> <201209041210.07555.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
John Baldwin writes:
> On Tuesday, September 04, 2012 7:10:42 am Sam Varshavchik wrote:
> > Konstantin Belousov writes:
> >
> > > The procfs links, as well as any other user of vn_fullpath(9) function,
> > > can only translate a vnode to path if namecache contains useful data.
> > > As such, the facilities are not guaranteed to success all the time.
> > >
> > > In case of rmdir(2), UFS explicitely purges the cache for directory which
> > > contained direntry of the removed directory. I suspect that you have
> > > your test program binary located in the same directory which was the
> parent
> > > of the removed one.
> >
> > Correct. Looks like the same thing applies if I try to use sysctl to get
> > KERN_PROC_PATHNAME.
> >
> > I need some reliable way to get a process's executable file's name, as long
> > as it's meaningful (the executable file hasn't been removed).
>
> There isn't one. What if the file is renamed, or what if it was executed via
> a symlink that has been removed?
If the file is renamed, shouldn't its new name be known? If I give the
file's supposed new name to realpath(3), its man page says I'll get back
the equivalent absolute pathname. Works for me.
And, I thought that the resolved pathname, in any case, would be the one
after all the symlink resolution takes place, like /proc shows on Linux: if,
say, I have /usr/local symlinked to /mnt/local-mnt,
exec("/usr/local/bin/furgle") gives me a process that, according to /proc,
is /mnt/local-mnt/bin/furgle.
> What if there are multiple hard links,
> which
> one is the "correct" path to return?
I would say whichever one of them was used to exec() the process. But either
one would be ok, I suppose.
> The namecache bits are a best effort,
> but
> if those are purged, the only approach are left with is a brute-force crawl
> of
> the filesystem looking for a file whose stat() results match your executable.
Well, for logging purposes, after I get a client process's credentials
passed through a domain socket, I was hoping to use the credentials' pid to
log the process's executable name. At least that's the code that I'm porting
is doing; but this is going to throw a big monkey wrench into the whole
thing.
Is the dev+ino of what was exec()ed known, for another process? I might be
able to get the client voluntarily submit its argv[0], then independently
have the server validate it by stat()ing that, and comparing the result
against what the kernel says the process's inode is.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEABECAAYFAlBGks8ACgkQx9p3GYHlUOK/bQCfS/SfvHkcG6qRYD3M0AYoBfB+
ll0AnRWaLVUFuz0F1iAHXMg8gcs+0yBz
=rr0X
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cone.1346802383.225884.23058.1000>