From owner-freebsd-hackers Mon Apr 8 16:23:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 862B837B405; Mon, 8 Apr 2002 16:23:28 -0700 (PDT) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.12.2/8.12.2) with ESMTP id g38NNRmG056823; Mon, 8 Apr 2002 18:23:27 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.2/8.12.2/Submit) id g38NNQrD056819; Mon, 8 Apr 2002 18:23:26 -0500 (CDT) Date: Mon, 8 Apr 2002 18:23:26 -0500 From: Dan Nelson To: Terry Lambert Cc: Michael Smith , Doug White , =?cp437?Q?Pawe=B3?= Jakub Dawidek , freebsd-hackers@FreeBSD.ORG Subject: Re: Hardlinks... Message-ID: <20020408232326.GB1749@dan.emsphone.com> References: <200204081841.g38Ifi104580@mass.dis.org> <3CB21C40.A62B442@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB21C40.A62B442@mindspring.com> User-Agent: Mutt/1.3.28i X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error 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 In the last episode (Apr 08), Terry Lambert said: > 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. So the user creates /tmp/zzz/ , chmod 0's /tmp/zzz, and sticks his link in there. > 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. But the question is "should execute permission on a directory imply link permission for all files in the directory?" If so, we'll have to move master.passwd and spwd.db out of etc, then. Into /etc/shadow/ (chmod 0) maybe? If the user can cd into the directory the file is in, he can link it elsewhere. You don't even need read permission on the directory. This might be a bit paranoid, as a problem only exists if the user later is able to gain root to access the files he stashed away earlier. The most paranoid admin would have to make sure that no world-writable directories exist on the same partition as files he wants to keep secure. > I think a patch that disallowed it entirely would break > /var/spool/lock based locking. 8-(. But for UUCP locking, you're linking a tempfile that you just created to the true lock name. You are linking from a file you own, which would be allowed even under the strictest lockdown of link. I think it'd work fine. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message