From owner-freebsd-stable@FreeBSD.ORG Thu Nov 28 07:04:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 249822FF for ; Thu, 28 Nov 2013 07:04:31 +0000 (UTC) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9BAF1949 for ; Thu, 28 Nov 2013 07:04:30 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g15so5402496eak.32 for ; Wed, 27 Nov 2013 23:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IRUOyC4vOxzx1SkOERRtzpmBrifu7T+EliAxadN7//Q=; b=bjdDjqRO01nx5m/vwgkh0cUF+hX6Fo3hay+Wd8faK8BUeRMloUY/cGwYocOH8PHNs+ QPCSVI9JjRlRuWMDpgV+qOozrEeuMBH4ZdPoCn/XICWfooPKXSdCPrw2xvYX3LTfZ1FR ZZ6KdpegCqofR0CQ89aqh42cLmZwFSX42r9GvoJk6lx0c9tTPoH8RnWtqrD9Pe7EWyc/ 9lk5olCZCWY8aQRgaT9Yo0ploQKJk0WHDOLToeeUR76a/rRhndlSojMbl0xhIPtRzou4 2kLYog/ExEOMlJ9B29Ue/cTONhPKevvauWCjAUKuTrHv9E9rigv9b+hRmd/ceqXPMyQr 03Uw== X-Received: by 10.14.0.72 with SMTP id 48mr4228873eea.50.1385622268980; Wed, 27 Nov 2013 23:04:28 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id a45sm26751318eem.6.2013.11.27.23.04.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 23:04:28 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Feature request: sticky bit inheritance Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1250 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <5295DF79.8060400@omnilan.de> Date: Thu, 28 Nov 2013 08:04:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FC93589-6AB1-4F43-98B3-C9281603A2AD@FreeBSD.org> References: <5295DF79.8060400@omnilan.de> To: Harald Schmalzbauer X-Mailer: Apple Mail (2.1283) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 07:04:31 -0000 Wiadomo=9C=E6 napisana przez Harald Schmalzbauer w dniu 27 lis 2013, o = godz. 13:03: > Hello, >=20 > ever since I took a FreeBSD machine into production, acting as any = kind > of file server, I have to work arround the problem, that write access = to > a directory implies unlinking (deleting) directory contents. Never = heard > any sensible explanation why anybody would ever want that behaviour, = but > it's been like that for decades and everybody seems to be fine with > that!?! Maybe because there's the stick bit, which is a usable = workarround. > Unfortunately, there's no =93sticky=94 equivalent in nfs4acls. One idea is to use NFSv4 ACLs and add entry that denies delete_child and is inherited by directories, i.e. "everyone@:D:d:deny". This should prevent deletion despite write access. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body?