Hard Links between UNIX Utility Programs

[M. D. Parker]

In article <184 at chip.UUCP>, mparker at chip.UUCP (M. D. Parker) writes:
> I have noticed the tendency for some programs in UNIX to have hard links.
> The program operation is then determined by the name it was invoked by.
> As a system administrator this makes it very difficult for me to restrict
> one program without restricting all their linked set.  And the problems
> is not just simply removing the hard link, since experimentations have
> proved that symbolic links do the same.  Thereby preventing restriction
> again.
> 
> I'd like to request that in future releases, this short-cut be eliminated.
> 

Seems from the messages, I have generated a bit of confusion.  Therefore,
perhaps a simple example taken from real life.  I want to prevent users from
examining the mailq using the /usr/ucb/mailq program because I feel that
who a user sends mail to should not be subject to disclosure to others.

Problem seems simple, perform a chmod on /usr/ucb/mailq and all is well.

Complication comes because /usr/ucb/mailq and /usr/lib/sendmail are HARD
LINKED together.  CHMODing one does the same for the other.

First try.  Make another copy of /usr/ucb/sendmail and call it /usr/ucb/mailq.
Programs no longer have HARD LINKs and can be protected individually.
Complication here, if a user creates a SYMBOLIC LINK to the program as:

	ln -s /usr/lib/sendmail mailq

and then executes the program 'mailq', the effect is identical to running
/usr/ucb/mailq prior to my making the copy.  In otherwords, since the 
program is scanning the argument list for its name it was invoked by, my
protection is VERY limited.  I am therefore unable to do what I originally
want, i.e. to restrict the mailq program.

For the above reason, deletion and removal of the HARD LINK will not work.

My only fix, if I had sources, would be to compile seperate versions of 
these linked programs so that the argument list check would be inhibited.
However, without source it is nearly impossible to correct.

Therefore, the easiest way to fix this is if people on the development side
would not rely on this technique. Hmm...be an interesting way to get a
privledged trojan horse into the system wouldn't it by hiding it into 
an install.  Think about this one the next time you install code obtained
from the outside.


===============================================================================
M. D. Parker			ARPANet: chip!mparker at nosc.mil
UNIX Systems Manager		UUCP: ...{ucsd,nosc,hp-sdd,crash}!chip!mparker
				Phone: (619) 457-2340

USPS: M/A-COM Government Systems, 3033 Science Park Road, San Diego, CA 92121

Disclaimer:	Opinions expressed are my own and not necessarily that of
		M/A-COM Government Systems Inc.