Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Apr 2002 18:23:26 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Michael Smith <msmith@FreeBSD.ORG>, Doug White <dwhite@resnet.uoregon.edu>, =?cp437?Q?Pawe=B3?= Jakub Dawidek <nick@garage.freebsd.pl>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Hardlinks...
Message-ID:  <20020408232326.GB1749@dan.emsphone.com>
In-Reply-To: <3CB21C40.A62B442@mindspring.com>
References:  <200204081841.g38Ifi104580@mass.dis.org> <3CB21C40.A62B442@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020408232326.GB1749>