From owner-freebsd-hackers Mon Jan 29 16:04:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA25121 for hackers-outgoing; Mon, 29 Jan 1996 16:04:46 -0800 (PST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA25102 for ; Mon, 29 Jan 1996 16:04:32 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP id QQaarg09946; Mon, 29 Jan 1996 19:04:22 -0500 (EST) Received: from uanet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Mon, 29 Jan 1996 19:04:28 -0500 Received: by crocodil.monolit.kiev.ua; Tue, 30 Jan 96 01:27:09 +0200 Received: (from dk@localhost) by dog.farm.org (8.6.11/dk#3) id BAA12731; Tue, 30 Jan 1996 01:27:47 +0200 Date: Tue, 30 Jan 1996 01:27:47 +0200 From: Dmitry Kohmanyuk Message-Id: <199601292327.BAA12731@dog.farm.org> To: jmacd@CS.Berkeley.EDU (Josh MacDonald) Cc: freebsd-hackers@freebsd.org Subject: Re: sticky directory symlinks Newsgroups: cs-monolit.gated.lists.freebsd.hackers Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org Precedence: bulk In article you wrote: > I apologize if this has been discussed before, though I couldn't > find anything on the subject. I asked a NetBSD user and he said > he recalled some discussion on this topic but didn't recall the > results. I just encountered the following problem: > axis-/tmp % ls -ld . > drwxrwsrwt 4 root wheel 512 Jan 25 00:46 ./ > axis-/tmp % ln -s this sucks > axis-/tmp % ls -l sucks > lrwxrwsrwt 1 root wheel 4 Jan 25 00:46 sucks@ -> this > axis-/tmp % rm sucks > rm: sucks: Operation not permitted > /tmp is mode 1777 and when I create a symlink I can't remove it. > I notice that the link shares the sticky dirs inode. I think from my understanding, 4.4BSD doesn't have any inode info for symlink, but rather inherits the information from directory containing the symlink. >From the symlink(7) manual page: Unlike other filesystem objects, symbolic links do not have an owner, group, permissions, access and modification times, etc. The only at- tributes returned from an lstat(2) that refer to the symbolic link itself are the file type (S_IFLNK), size, blocks, and link count (always 1). The other attributes are filled in from the directory that contains the link. For portability reasons, you should be aware that other implemen- tations (including historic implementations of 4BSD), implement symbolic links such that they have the same attributes as any other file. see /sys/kern/vfs_syscalls.c:lstat() for the actual code. > this is very very bad. I guess that an optimization is made > where the linkname is kept in the directory file instead of > on disk but if its a sticky directory, then I can't remove > something I create. That sucks a lot. Has this been brought > up before? another 4.4BSD optimization is that for short symlinks, the name of the link is stored in the inode instead of inside of separate disk block if it is sufficiently short to fit there (struct mount->mnt_maxsymlinklen). (the code is in /sys/ufs/ufs/ufs_vnops.c). But this is irrelevant here. -- No matter how subtle the wizard, a knife in the shoulder blades will seriously cramp his style.