What happened to my /proc/curproc/file?

[Sam Varshavchik]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120904/78879f55/attachment.pgp