From owner-freebsd-security Wed Feb 28 06:26:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA11004 for security-outgoing; Wed, 28 Feb 1996 06:26:20 -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 GAA10996 for ; Wed, 28 Feb 1996 06:26:17 -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 GAA10572; Wed, 28 Feb 1996 06:18:32 -0800 (PST) From: Cy Schubert - BCSC Open Systems Group Message-Id: <199602281418.GAA10572@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: Bruce Evans cc: roberto@keltia.freenix.fr, msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@freebsd.org Subject: Re: Suspicious symlinks in /tmp In-reply-to: Your message of "Wed, 28 Feb 96 18:30:59 +1100." <199602280730.SAA31286@godzilla.zeta.org.au> Date: Wed, 28 Feb 96 06:18:31 -0800 X-Mts: smtp Sender: owner-security@freebsd.org Precedence: bulk > >> I think this is to conform to future POSIX standards. Many other things > >> involving symlinks changed in 4.4lite. See `man 7 symlink'. > > >davidg also said it was not to use an inode for the symlink itself so every > >symlink in 4.4BSD are fast symlinks (as it was possible to use in FreeBSD > >1.1.5.1). > > Fast/small symlinks use an inode but not a data block. Very fast/small > symlinks would use only a directory entry (or two). Then there would be > nowhere to store the uid etc. > > >It don't like our behaviour either. Highly counterintuitive and deadly for > >sticky directories too where a user can't remove a link he made. > > Very intuitive if you don't know about inodes :-). > > Bruce > Why not kernel config option??? Let the sysadmin decide whether he/she wishes to implement the feature or not. Of course this would require a somewhat significant change to the filesystem creating two types of symbolic link objects, one that would be defined in a directory entry and the other which would be defined in an inode. One which would give you better performance while the other better user friendliness. The reason you need to have both types defined is when a kernel reconfig is performed the type of symbolic link that is not defined in the kernel config would still be followed but not created. An FSCK option could be added to make all symbolic links on a filesystem consistent with the kernel definition. It's just a thought... 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."