From owner-freebsd-hackers Tue Jun 15 4: 1: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.vnet.net (smtp2.vnet.net [166.82.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 5186214C3B for ; Tue, 15 Jun 1999 04:00:58 -0700 (PDT) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp2.vnet.net (8.9.1a/8.9.1) with ESMTP id HAA16761; Tue, 15 Jun 1999 07:00:42 -0400 (EDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id HAA16006; Tue, 15 Jun 1999 07:00:00 -0400 (EDT) Received: (from rivers@localhost) by lakes.dignus.com (8.9.2/8.6.9) id GAA53375; Tue, 15 Jun 1999 06:59:58 -0400 (EDT) Date: Tue, 15 Jun 1999 06:59:58 -0400 (EDT) From: Thomas David Rivers Message-Id: <199906151059.GAA53375@lakes.dignus.com> To: jkh@zippy.cdrom.com, syssgm@detir.qld.gov.au Subject: Re: symlink question Cc: cyouse@cybersites.com, hackers@FreeBSD.ORG, mrami@gbtb.com In-Reply-To: <2743.929428404@zippy.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > symlinks have caused me grief (Pyramid OSx) and never joy. I hope it fails > > yet again to appear in FreeBSD. Just think of the new security holes for a > > start. > > Name one, please. You can currently point a symlink anyplace you > like; whether the user has permission to *read* or execute the target > of the link, however, is where the genuine system administration takes > over. How the actual value is derived shouldn't make that much > difference. :) > > - Jordan > My biggest problem with variant symlinks (which I've preached on before) is the following scenario: o) User A runs program P which takes advantage of a variant symlink in some fashion (either in finding P or finding some data P needs, etc...) o) User B runs program P which fails miserably. o) The sysadmin notes that the machines are the same, the symlinks are the same... then has to track down user B, and has to determine what variant symlinks P has been (perhaps even unaware to the designers of P) using and then has see what in user B's environment is causing this problem. Muliply B by several hundred... We would have problems like that on our Apollos; learning the hard way to avoid variant symlinks... just to ensure the environment was as expected. You don't have these same questions with "plain" symlinks. And, if the symlink changes, it's quite easy to see that it changed... So - I'd say that variant symlinks are like many other things, it's really easy to shoot yourself in the foot.. In my opinion variant symlinks make it too easy. Sometimes nifty things don't need to be done. I'd suggest that if they were implemented in FreeBSD - we leave the support 'off' by default, with a sysctl variable to enable them. When a user posts that his XXX/YYY/ZZZ directory has "gone away" we can ask, "are variant symlinks turned on?" and have a good first guess as to the culprit. Just my thoughts.... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message