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
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.
--=_monster.email-scan.com-23058-1346802383-0006
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
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.
--=_monster.email-scan.com-23058-1346802383-0006
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEABECAAYFAlBGks8ACgkQx9p3GYHlUOK/bQCfS/SfvHkcG6qRYD3M0AYoBfB+
ll0AnRWaLVUFuz0F1iAHXMg8gcs+0yBz
=rr0X
-----END PGP SIGNATURE-----
--=_monster.email-scan.com-23058-1346802383-0006--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cone.1346802383.225884.23058.1000>