Finding where an executable was run from -- a proposal.

[Andrew Burt]

In article <4626 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>mer6g at 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.

If all you need is a secure method of obtaining a single pathname (e.g., for
the lib dir of an application) why not use [**kludge alert**] a dummy
entry in /etc/passwd with home dir set to the path desired (actual login
disabled, of course)?  Program wanting to know its lib dir just does
getpwnam(compiled_in_application_id) and off it goes.

Now I hate to junk up /etc/passwd with this sort of thing (and have an
alternative suggestion below) but this is easily done with current tools.
I'd like to see a convention on usernames chosen for application "users",
maybe prepending an underscore to a simple name for the application (_uucp,
_news, _nethack, etc.).  Admittedly this isn't needed but it makes it
more obvious the entry isn't for a real user.

What would even be more useful (and what this approximates in an ugly way)
is a global environment (that isn't user changeable).  A true global env.
could be implemented by a lib func (getsysenv(var_name)) that looks for
"var_name=..." in a file, /etc/environment say.  (Granted, we could make
this a system call and store the environment in core all the time, but it
strikes me programs wouldn't look up definitions so often that much time
would be saved.)  Makes the system admin job easier too.  I always feel
a little uneasy editing passwd (I dial in on often noisy phone lines), I'd
feel better editing a less crucial file.

Implementation-wise there's not much to this -- anyone who wants a copy
let me know -- but there is the problem of getting it universally adopted.
The passwd approach has the advantage that the file exists and people know
what it does.  (On the other hand, the /etc/environment would be more
adoptable for non-unix systems where there is no passwd...)

Thoughts anyone?
-- 

Andrew Burt 				   			isis!aburt

              Fight Denver's pollution:  Don't Breathe and Drive.