From owner-freebsd-arch@FreeBSD.ORG Mon Jan 1 10:41:34 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 877D816A40F; Mon, 1 Jan 2007 10:41:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5712413C44C; Mon, 1 Jan 2007 10:41:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6290948681; Mon, 1 Jan 2007 05:41:33 -0500 (EST) Date: Mon, 1 Jan 2007 10:41:33 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Bruce Evans In-Reply-To: <20070101205016.U3544@epsplex.bde.org> Message-ID: <20070101103544.T7974@fledge.watson.org> References: <459745DA.1010801@freebsd.org> <20061231153329.Y8131@fledge.watson.org> <20070101205016.U3544@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Colin Percival , "freebsd-arch@freebsd.org" Subject: Re: default value of security.bsd.hardlink_check_[ug]id X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2007 10:41:34 -0000 On Mon, 1 Jan 2007, Bruce Evans wrote: > On Sun, 31 Dec 2006, Robert Watson wrote: > >> I'm not entirely happy with the current implementation, FWIW. I'd like >> can_hardlink to be implemented in the per file system code, possibly by >> invoking a common routine of this sort, avoiding the extra call to >> VOP_GETATTR(), and allowing file systems not implementing ownership in >> traditional ways (msdosfs, etc) to do whatever makes sense in their >> context. On the whole, these sorts of decisions are made in each file >> system, often using common code (perhaps centralized), and not at the VFS >> layer. > > I think it also has wrong semantics. It denies privilege based on > non-ownership, while everything that uses vaccess() grants privilege based > on ownership. This gives the surprising behaviour that if > hardlink_check_gid = 1, the owner of a file can do anything to the file > except link to it in cases where the group of the file isn't in the caller's > group list (and no immutable but is set). Yes, I think you're right. Per our earlier thread on the structure of privilege checks on arch@, security checks generally shold look something like this: error = dac_check(cred, object); if (error) { error = priv_check(cred, privilege); if (error) return (error); } The requirement for ownership or privilege for linking is part of the DAC check in this structure. Operations seem to fall down into three categories: - Operations always requiring privilege. - Operations requiring ownership or privilege. - Operations requiring rights be granted via the ACL or privilege. There may be a few edge cases requiring ownership, ACL, or privilege, but these may also be bugs. I think we should always allow linking rights for the owner and for privilege, and optionally also for the group or everyone. So perhaps we want a linking mib entry that selects one of the following "levels" for hard linking: - Privilege required. - Ownership or privilege required. - Matching group or ownership or privilege required. - Allowed for everyone. Robert N M Watson Computer Laboratory University of Cambridge