Date: Fri, 7 Sep 2012 10:33:52 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Sam Varshavchik <mrsam@courier-mta.com> Subject: Re: What happened to my /proc/curproc/file? Message-ID: <201209071033.52864.jhb@freebsd.org> In-Reply-To: <cone.1346802383.225884.23058.1000@monster.email-scan.com> References: <cone.1346723177.448775.23058.1000@monster.email-scan.com> <201209041210.07555.jhb@freebsd.org> <cone.1346802383.225884.23058.1000@monster.email-scan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 04, 2012 7:46:23 pm Sam Varshavchik wrote:
> 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.
What if it was renamed by a different NFS client? :)
Also, files don't have backreferences to all their open file descriptors.
Even if they did they would have to have different sets for different paths.
That is a lot of overhead to maintain in the kernel, and it isn't maintained.
All the kernel effectively has internally is an i-node.
> 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.
That is what you would get by reverse-walking the name cache for
/proc/curproc/file as well.
> > 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.
Do you need the whole path or just the command name? The command name is
stored in the kernel, and if you know the other process' pid you can fetch
that via kvm_getprocs().
> 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.
It's known in the kernel certainly. I don't think we currently have any way
of exporting that info to userland however.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209071033.52864.jhb>