Xref: utzoo comp.unix.wizards:8706 comp.sources.d:2157
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.unix.wizards,comp.sources.d
Subject: Re: Finding where an executable was run from -- a proposal.
Message-ID: <4626@hoptoad.uucp>
Date: 23 May 88 00:45:17 GMT
References: <52873@sun.uucp> <107@lakart.UUCP> <78@uvaarpa.virginia.edu>
Organization: Grasshopper Group in San Francisco
Lines: 45

mer6g@uvaarpa.virginia.edu (Marc E. Rouleau) wrote:
> The whole point of John Gilmore's proposal was to address this problem
> of executables being found by path-search and therefore having no
> invocation-time knowledge of where they reside.

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.
Imagine if you could invoke uucp with your own private set of spool
directories -- all the security built into it would be pretty useless.
You could steal mail, forge things, etc.

Several people pointed out that hard links to a program would foul up
my proposed mechanism -- they are right.  You can prevent people from
copying the application to another spot and running it (by making the
program unreadable by mortals, even though executable by them); the
kernel could resolve all the symlinks before giving you the path; but
you can hard-link to anything you can name, even if it has '0'
permissions.

Perhaps a solution is to only provide this facility to programs with a
link count of 1?  In other words, if you hard-link to a program, it
would no longer be provided its name, and could exit with an error
message.  This is probably even worse -- by simply creating a hard link
to /usr/lib/uucico, you could make it unable to find its directories,
even when run from the right place.

Perhaps a variation on one of these themes would work.  If the kernel
was to output pathnames to user programs (presumably so that the
programs can trust that the pathnames are uncorrupted), it might
be reasonable to put some kinds of access control on hard links.
Maybe if/when Unix file protection ever gets revised, this can be
considered.

Someone else pointed out that Multics can reliably tell you the
pathname of your running program.  Maybe Multics didn't have hard
links, so it was trustable?
-- 
John Gilmore  {sun,pacbell,uunet,pyramid,ihnp4}!hoptoad!gnu        gnu@toad.com
"Use the Source, Luke...."