[vox-tech] Identifying the directory that contains the currently running executable?

[Peter Jay Salzman]

On Fri 27 Aug 04, 11:21 AM, ME <dugan at passwall.com> said:
> Ken Bloom said:
> > I guess that solves the C program problem, because I can use getpid()
> > to fill in the blank, and readlink(2) to find the elf executable.
> >
> > That is one wierd symlink. ME wrote in May
> > (http://www.lugod.org/mailinglists/archives/vox-tech/2004-05/msg00247.html)
> > about deleting the executable file, then recovering it from
> > /proc/$PID/exe, so I had assumed it wasn't a symlink. Looking at it
> > harder, symlinks can't usually point to deleted files [1], but this one
> > can! You can recover the exe with cat, but not with cp. Really wierd.
> 
> Well, the /proc filesystem is not a "normal" filesystem, but is more like
> a kind of collection of data stored in memory and "pointers" to other
> data.
> ("Normal" meaning it is not used so much to create files on a disk as we
> think files exists on disks.)
> 
> I think that the behavior you see when accessing the symlink is one of two
> properties or a combination of two properties:
> 1) A file is not actually deleted until all link to the file are destroyed
> (not talking symlinks) and all processes that have opened that file, close
> the file. (The file may not be listed as available for opening if all the
> links to it are gone, but I do not think the file space is freed by the
> filesystem until the last process with the file open closes it-- could be
> wrong here.)
> 2) The file that is loaded into memory can effectively be written fromm
> memory back out to a file. The thing that looks like a symlink in proc may
> not actually be a conventional symlink.
> 
> I have not looked at proc in detail enough as of late to see how much each
> of these play a role in grabbing copies of deleted applications from proc
> if they are still running on the system.

from fs/proc/base.c, it appears that spin locks are used to make sure that
/proc/# (including /proc/#/exe) isn't unlinked until after the attach count
for the process drops to zero.  note that i said "attach count for a process
drops to zero", and not, "when the disk file is unlinked".

the reason is to avoid a race condition.  if detach_pid(A) is called before
/proc/A/ is cleared from the dcache, it's possible for another process to be
created that reuses pid A.  If this happens, exe is wrong, maps is wrong,
stat is wrong, etc.  classic race condition.

to the eyes of filesystem, it is a symlink, but as ME points out, it's
resident in memory, not disk.  access of /proc files is governed by an
interface determined by the author of that piece of kernel code.

i'm not sure why cp can't be used to make a new copy of the executable when
cat can.  when it comes down to it, cat and cp are the same program: they
open, they read, they write, and they close.  so i guess i concur -- it IS
wierd.  :)

pete

ps- if someone wants to file a bug report, the word "synchroneous" is
incorrectly spelled in the comments of base.c (as of linux 2.6.7).  :)

-- 
Make everything as simple as possible, but no simpler. -- Albert Einstein
GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D