Xref: utzoo comp.unix.wizards:8769 comp.sources.d:2165
Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!gargoyle!att!cuuxb!dlm
From: dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
Newsgroups: comp.unix.wizards,comp.sources.d
Subject: Re: Finding where an executable was run from -- a proposal.
Summary: the /proc feature allows this
Message-ID: <1804@cuuxb.ATT.COM>
Date: 24 May 88 18:39:37 GMT
References: <52873@sun.uucp> <107@lakart.UUCP> <78@uvaarpa.virginia.edu> <4626@hoptoad.uucp>
Reply-To: dlm@cuuxb.UUCP (Dennis L. Mumaugh)
Organization: ATT Data Systems Group, Lisle, Ill.
Lines: 47

In article <4626@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>Actually, that's not the point (you could always write a subroutine
>that searched the path to find argv[0]).  The point is that I want a
>mechanism that cannot be spoofed.  Mystery variables in the
>environment, library routines that look at argv[0], etc, can all be
>spoofed by a 3-line program (that changes the environment then calls
>exec(), or that passes different things as the filename to execute
>versus argv[0] to exec()).  If real applications are going to use this,
>it's critical that they are able to depend upon the pointer they find.

There is such a facility that originated in Version 8  that  will
see  light  of  day in NEW ATT releases of UNIX.  This is part of
the /proc file system.  It  is  an  ioctl  that  returns  a  file
descriptor of the text of the process.
    PIOCOPENT -- provides a read-only  file  descriptor  for  the
    executable  file  associated with the "traced" process.  This
    allows a debugger to find the symbol table without having  to
    know any path names.

Once you have the file descriptor, fstat it and get  the  device,
inode  pair,  and then execute ncheck -i on the correct device to
get a path name.  Of course  this  is  modulo  links  (  hard  or
symbolic).

What?  You must be root to run ncheck?  True, but why  would  you
be so concerned about being lied to otherwise.

Actually, the PIOCOPENT would have been very useful  for  the  V6
Adventure  game that Jim Gillogly wrote.  He put the messages for
the game at the end of the a.out following the "meaningful"  part
of  the  a.out.  His program did all sorts of contortions to find
the name of the file so it could be opened and read. [It  had  to
be installation and user independent/proff.]

With the ioctl from /proc, it would be a three line code section:

	sprintf(procname,"/proc/%05d",getpid());
	procfd = open(procname,O_RDONLY);
	textfd = ioctl(procfd,PIOCOPENT);
	lseek(textfd, (long)offset,0);

So, if that is what you are really intending to do, use Version 8
or wait a year -- it is already available for System V Release 3.1. for
the 3B4000.
-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm