🚀 go-pugleaf

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.  The posting wasn't clear about
  what he wanted "restricted" to mean, but consider something like this:
  imagine that telnet was set up to use this link hack: if you start it with
  some host-name, it'll just connect you to that host.  So you now have:
       telnet
       ln telnet myhost1
       ln telnet myhost2
       ln telnet myhost3
	...
  Now, imagine that you are under "orders" to limit access to, say, the
  arpanet.  Thus, no more allowing folk to "free form" 'telnet your.host.edu'.
  Well, you can rm telnet, and in fact ONLY leave around the "myhostN"s that
  correspond to the hosts you are willing to allow the users to access (this is
  the moral equivalent of what you suggested, but actually rm'ing the
  restricted versions instead of just unlinking them).  Now what?  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.

   __
  /  )                              Bernie Cosell
 /--<  _  __  __   o _              BBN Sys & Tech, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_             cosell@bbn.com