Date: Mon, 8 Mar 2004 21:25:55 +1100 From: Tim Robbins <tjr@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-security@freebsd.org Subject: Re: Call for review: restricted hardlinks. Message-ID: <20040308102555.GA85110@cat.robbins.dropbear.id.au> In-Reply-To: <20040308093642.GI10864@darkness.comp.waw.pl> References: <20040308093642.GI10864@darkness.comp.waw.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 08, 2004 at 10:36:42AM +0100, Pawel Jakub Dawidek wrote: > Hi. > > I've no response from so@ in this topic, probably because leak of time, > so I'll try here. > > Here is a patch that I'm planing to commit: > > http://people.freebsd.org/~pjd/patches/restricted_hardlinks.patch > > It adds two new sysctls: > > security.bsd.hardlink_check_uid > security.bsd.hardlink_check_gid > > If sysctl security.bsd.hardlink_check_uid is set to 1, unprivileged users > are not permitted to create hard links to files not owned by them. > If sysctl security.bsd.hardlink_check_gid is set to 1, unprivileged users > are not permitted to create hard links to files if they are not member > of file's group. > > For now user is able to create hardlinks to any files. It might be more consistent with other UNIX access checks (e.g. vaccess()) if having the same uid as the file was sufficient to link to it, without having to be a group member. I can't convince myself either way on this, but it's worth thinking about. Also be aware that as a side effect of this patch, old applications that use the unlink()/link()/unlink() sequence instead of the rename() system call may not be able to rename files they don't own. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040308102555.GA85110>