From owner-freebsd-hackers Mon Apr 8 15:41:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id BD30437B400; Mon, 8 Apr 2002 15:41:14 -0700 (PDT) Received: from pool0490.cvx40-bradley.dialup.earthlink.net ([216.244.43.235] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16uhoH-00055O-00; Mon, 08 Apr 2002 15:40:25 -0700 Message-ID: <3CB21C40.A62B442@mindspring.com> Date: Mon, 08 Apr 2002 15:40:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Smith Cc: Doug White , "=?iso-8859-1?Q?Pawe=B3?= Jakub Dawidek" , freebsd-hackers@FreeBSD.ORG Subject: Re: Hardlinks... References: <200204081841.g38Ifi104580@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Michael Smith wrote: > You misunderstand the original poster's complaint. > > The issue is that a non-owner can cause the owner's file to remain alive > even after the owner has deleted it. Hence the comment about "later > breakin". > > You could also use this technique to maliciously exhaust a user's quota, > by linking to their temporary files. I'm not sure what the standards > have to say about this, but I don't much like the current behaviour. I think that making the links in temporary directories should not be allowed, by dint of the t bit in the user of the directory in which the file is being created. I think the problem with someone else making a link to my file and keeping it around is an issue of access controls to the file itself, and not really a problem: e.g. if you want to avoid it, don't rely on obscurity, and don't permit exterior access to the files. Actually, people have complained about not having a "flink(2)" call to create a directory entry for an open file. I think if this were there, then the problem would be genuine; but without it, it's a matter of controlling access to the files. I wouldn't be opposed to a patch that prevented creation of links to files you don't own, if the 't' bit were set on the wource or destination directory, but which would permit the operation otherwise. I think a patch that disallowed it entirely would break /var/spool/lock based locking. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message