Xref: utzoo comp.bugs.4bsd:865 comp.bugs.misc:156 comp.bugs.sys5:491
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!joyce!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.bugs.4bsd,comp.bugs.misc,comp.bugs.sys5
Subject: Re: Hard Links between UNIX Utility Programs
Keywords: unix links restriction
Message-ID: <198@quintus.UUCP>
Date: 27 Jul 88 05:00:12 GMT
References: <184@chip.UUCP> <2950@ci.sei.cmu.edu> <27498@bbn.COM>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 43

In article <27498@bbn.COM> cosell@bbn.com (Bernie Cosell) writes:
>In article <2950@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes:
>}You can get exactly the effect you want by just eliminating the links
>}and making discrete copies of the program under the different names.
>}You can then protect the individual copies as you wish.

>  I thought of this, too, but it doesn't work.
...
>  Well, the first enterprising user to figure out that
>      ln -s /wherever/myhost1 telnet
>  in his home directory will REENABLE the telnet access you so carefully tried
>  to turn off.  If the user has a directory on the right filesystem, he can
>  even use a hard link, or copy the executable to a new name or whatever.
>
>  Altogether, it is not easy to fix.

Since a program can supply any string it likes in argv[0], even forbidding
every sort of link altogether wouln't permit the original poster to do what
he apparently wants.  To continue with the telnet example:

	main(argc, argv, envv)
	    int argc;
	    char **argv;
	    char **envv;
	    {
		char *realprog = "/wherever/myhost";

		argv[0] = "telnet";
		execve(realprog, argv, envv);
		perror(realprog);
		exit(1);
	    }

The problem isn't links: it's programs which decide what to do based on
their name.  But the name is just another argument.  The problem, then,
is that if there is one program which can do several operations, depending
on an argument to determine which, you can't give a user permission to
do some of the operations without giving him permission to do all of them.
This is a surprise?

It might be possible to put the program in a special group, which none of
the restricted users belongs to, and write a set of set-group-id shell
scripts to call the program appropriately.  Then restricted users couldn't
get at the program directly, and couldn't fake it through the scripts.