From owner-freebsd-questions@FreeBSD.ORG Sat Jan 15 12:53:26 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E5F1065673 for ; Sat, 15 Jan 2011 12:53:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 396F68FC15 for ; Sat, 15 Jan 2011 12:53:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id p0FCrP8U012023; Sat, 15 Jan 2011 23:53:25 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 15 Jan 2011 23:53:25 +1100 (EST) From: Ian Smith To: perryh@pluto.rain.com In-Reply-To: <4d31714c./ou+xrju7k5Jpolu%perryh@pluto.rain.com> Message-ID: <20110115231949.M62193@sola.nimnet.asn.au> References: <20110114032629.8042C1065782@hub.freebsd.org> <20110115003107.O62193@sola.nimnet.asn.au> <4d31714c./ou+xrju7k5Jpolu%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: swegill@gmail.com, freebsd@edvax.de, freebsd-questions@freebsd.org Subject: Re: httpd-modsec2_debug.log: Operation not permitted X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 12:53:26 -0000 On Sat, 15 Jan 2011, perryh@pluto.rain.com wrote: > Ian Smith wrote: > > > Swe, I suspect the reason you can't just delete these files is > > likely because something has them open for writing, and the system > > won't let you remove such files, naturally enough. > > Really? Must be a fairly recent change -- and IMO not necessarily > a good one. For one thing, it would break one of the long-standing > methods for ensuring that scratch files get cleaned up when a > program exits, even under circumstances which don't allow for signal > handlers to be run. Hmm, on reflection you're probably right. I was thinking that removing a file being written by a root-owned process would force that process to fail on write and exit, but maybe that's not what's happening here. > Last I knew having a file open, even for writing, was no protection > against its last link being removed. The _inode_ won't go away > until the last handle is closed, but the _directory entry_ can still > be removed. Accepting that, why wouldn't root be permitted to rm these files? It's been shown that they don't have immutable, append-only or other flags set. Clearly the filesystem is writable, if full. I'm still curious about what fstat reveals, and it'd be extra weird if they can't be deleted or truncated in single-user mode, eh? cheers, Ian