Date: Thu, 28 Jul 2011 16:36:30 +0100 (BST) From: jan.grant@bristol.ac.uk To: perryh@pluto.rain.com Cc: freebsd-hackers@freebsd.org, rwatson@freebsd.org, s@samu.pl Subject: Re: Finding symlink information in MAC Framework Message-ID: <alpine.BSF.2.00.1107281632110.58073@tribble.ilrt.bris.ac.uk> In-Reply-To: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> References: <c0c76b43d88b48a8b354df409b5167e5@samu.pl> <alpine.BSF.2.00.1107250942340.51541@fledge.watson.org> <cdf7c352c5d4a2edc308a6e1ab7d63c0@samu.pl> <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Jul 2011, perryh@pluto.rain.com wrote: > s <s@samu.pl> wrote: > > > ... I am trying to compare the owner of the symlink to the owner > > of what the symlink points to ... At first I was trying to check > > wheter some user is trying to create such a symlink ... > > I've always considered the "ownership" and "permissions" of a > symlink to be an artifact of the implementation, rather than > having any real significance. > > Symlinks did not exist in Bell Labs Unix, at least as of > 6th edition. IIUC they were invented at UCB to get around > the limitation that a hard link could not cross a physical > filesystem boundary (i.e. a mount point); symlinks would > not have been needed had the entire logical filesystem been > contained on a single, unpartitioned physical device because > hard links could have been used instead. One additional thing that symlinks manage to do is to refer to directories as well as files; hard links to directories spawn problems such as requiring garbage collection and smarter filesystem descent algorithms, which is another reason they're typically prohibited except in the case where they're created by "mkdir". > Getting back to the original problem, suppose you had no mounted > filesystems (other than special cases like devfs or /proc), the > entire logical filesystem tree being stored on a single device, so > that any file on the system could be hard-linked into any directory > on the system. How would you detect that "some user" had created a > _hard_ link to some arbitrary file? FWIW one of the early unix systems I was exposed to permitted the creation of hard links by arbitrary users. This led to a denial of service situation whereby the original creators of files could be deprived of inodes in the quota system, and blocks too if they removed one of their files without checking if anyone else had it linked first. It was a multiuser system that hosted undergraduates, so obviously this wasn't just a theoretical problem. -- jan grant, University of Bristol. But not for much longer! Update your address books: jang@ioctl.org http://ioctl.org/jan/ Q: What's yellow and equivalent to the axiom of choice? A: Zorn's lemon.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1107281632110.58073>