From owner-freebsd-current@FreeBSD.ORG Thu Nov 28 00:06:02 2013 Return-Path: Delivered-To: freebsd-current@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 6D835748 for ; Thu, 28 Nov 2013 00:06:02 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 245DA7C6 for ; Thu, 28 Nov 2013 00:06:01 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-246-96.lns20.per2.internode.on.net [121.45.246.96]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rAS05u90032756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 27 Nov 2013 16:05:59 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <529688DF.2010600@freebsd.org> Date: Thu, 28 Nov 2013 08:05:51 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Harald Schmalzbauer Subject: Re: Feature request: sticky bit inheritance References: <5295DFAD.5070402@omnilan.de> <52960DB5.3090209@freebsd.org> <52961B25.3020109@omnilan.de> In-Reply-To: <52961B25.3020109@omnilan.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 00:06:02 -0000 On 11/28/13, 12:17 AM, Harald Schmalzbauer wrote: > Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localtime): >> On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote: >>> Hello, >>> >>> 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. >> not sure I fully understand what you mean by that.. >> Do you mean write access implies delete access? yes.. >> >> This can be modified with the nounlink flag. > The uunlink flags also prohibits the owner to delete his files as far as > I know. I want to prohibt users from deleting “foreign” files, even if > the user has write access to the parent directory (and I wanted to > explain that I don't understand why anybody would want that a user with > write access to a directory can delete files on which the user doesn't > have write access). You can always unlink a file that is not yours if you own the directory. because the ability to unlink is purely dependent on the directory. You don't change the file, and it may in fact have other links The 'nounlink' flags change this. > The sticky bit exactly does what I need (and should be the default > behaviour in my opinion). > But my problem is that the stick bit must be added to each single > directory after creation, it's not inherited. correct. > I'd need every child directory of directories, who have the sticky bit > set, also to have the sticky bit. The same behaviour as with the gid – > it's the same as the parent has for new directories. "patches accepted" :-) I don't think that you are going to have much chance in changing default unix behaviour, but a patch (that can be disabled) would have a chance if there was a really good reason for it. > > Thanks, > > -Harry >