Date: Mon, 08 Apr 2002 21:13:12 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Michael Smith <msmith@FreeBSD.ORG>, Doug White <dwhite@resnet.uoregon.edu>, "=?iso-8859-1?Q?Pawe=B3?= Jakub Dawidek" <nick@garage.freebsd.pl>, freebsd-hackers@FreeBSD.ORG Subject: Re: Hardlinks... Message-ID: <3CB26A58.AD809508@mindspring.com> References: <200204081841.g38Ifi104580@mass.dis.org> <3CB21C40.A62B442@mindspring.com> <20020408232326.GB1749@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > > 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 you can copy it, you should be allowed to link it; if you can't, then you shouldn't. > 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. The ability to link to files you don't have read access to is rather ridiculous. The patch that was proposed, though shot you in the head, even if you do have read access (e.g. as in a "LCK..tty0" file). It's arguable that "/" and "/usr" themselves should be mounted read-only, and that /tmp should be "elsewhere", though, so this could be portrayed as an administrative issue, not a kernel issue. > > 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. Think "lock override due to ``kill -0'' giving ESRCH instead of EPERM or success". -- Terry 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?3CB26A58.AD809508>