From owner-cvs-src@FreeBSD.ORG Wed Dec 13 15:51:10 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 41C5816A522; Wed, 13 Dec 2006 15:51:10 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39CF243D46; Wed, 13 Dec 2006 15:49:35 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 79F7D5A1C63; Thu, 14 Dec 2006 02:51:03 +1100 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 8917E8C07; Thu, 14 Dec 2006 02:51:02 +1100 (EST) Date: Thu, 14 Dec 2006 02:51:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek In-Reply-To: <200612131322.kBDDMwlN082116@repoman.freebsd.org> Message-ID: <20061214023620.A1178@besplex.bde.org> References: <200612131322.kBDDMwlN082116@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/sys chmod.2 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2006 15:51:10 -0000 On Wed, 13 Dec 2006, Pawel Jakub Dawidek wrote: > pjd 2006-12-13 13:22:58 UTC > > FreeBSD src repository > > Modified files: > lib/libc/sys chmod.2 > Log: > Append-only flag also denies chmod(2). Is this correct behaviour? I don't like it, but it follows from a literal interpretation of "only". I think the append-only flag should only have applied to data, (including clobbering of the data by removing the file), but in some cases you may actually want the current semantics of the flag (immutable attributes (except for mtime and atime via append and read) together with immutable old-data), and there is currently no other way to specify this. The main incorrect behaviour near here is no-unlink denying chflags(2). This bug is is already documented (not as a bug). The no-unlink flag should at most deny chflags() of itself. Bruce