From owner-freebsd-security Wed Feb 28 06:05:49 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10178 for security-outgoing; Wed, 28 Feb 1996 06:05:49 -0800 (PST) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id GAA10168 for ; Wed, 28 Feb 1996 06:05:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.4/8.6.10) with SMTP id GAA10468; Wed, 28 Feb 1996 06:05:24 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602281405.GAA10468@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol Reply-to: cschuber@orca.gov.bc.ca X-Mailer: DXmail To: Michael Smith cc: nlawson@kdat.csc.calpoly.edu (Nathan Lawson), newton@communica.com.au, security@FreeBSD.ORG Subject: Re: Suspicious symlinks in /tmp In-reply-to: Your message of "Wed, 28 Feb 96 18:35:36 +1030." <199602280805.SAA16934@genesis.atrad.adelaide.edu.au> Date: Wed, 28 Feb 96 06:05:23 -0800 X-Mts: smtp Sender: owner-security@FreeBSD.ORG Precedence: bulk > Nathan Lawson stands accused of saying: > > > > > > So: Not only does it not matter who owns the symlink, it also doesn't > > > matter how it is chmod'ed. You can set its permissions to rwxrwxrwx > > > without making a spot of difference to the accessibility of the file > > > it's pointing at. > > > > Yes, but let's say Joe User tries out the ln -s command. Now he can't dele te > > his symlink. This behavior is broken. A user should not be able to create > > any type of file, whether a symlink or just a normal file, that is owned > > by another user. > > How's that supposed to work? To create it, he has to have write permissions > in the destination directory; the same are required to delete it. > > > Like I said before, how about a justification as to the usefullness of this > > behavior? I've already provided one annoying result of it. > > You haven't. The alternative behaviour would allow a user to create a symlin k > to a protected file, change the permissions on the link, and thus > access the file. Lose lose lose. It doesn't work that way. In every version of UNIX I've ever used the symlink's permissions are not referenced when the O/S decides to grant or deny permission to the file. The symlink is jist a pointer. > > Think of symlinks as a redirection, not a second instance of the file > (contrast hard links). > > > Nate Lawson > > -- > ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ > ]] Genesis Software genesis@atrad.adelaide.edu.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ > ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ > Regards, Phone: (604)389-3827 Cy Schubert OV/VM: BCSC02(CSCHUBER) Open Systems Support BITNET: CSCHUBER@BCSC02.BITNET BC Systems Corp. Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca "Quit spooling around, JES do it."