Date: Sat, 15 Jan 2011 23:53:25 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: perryh@pluto.rain.com Cc: swegill@gmail.com, freebsd@edvax.de, freebsd-questions@freebsd.org Subject: Re: httpd-modsec2_debug.log: Operation not permitted Message-ID: <20110115231949.M62193@sola.nimnet.asn.au> In-Reply-To: <4d31714c./ou%2Bxrju7k5Jpolu%perryh@pluto.rain.com> References: <20110114032629.8042C1065782@hub.freebsd.org> <20110115003107.O62193@sola.nimnet.asn.au> <4d31714c./ou%2Bxrju7k5Jpolu%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Jan 2011, perryh@pluto.rain.com wrote: > Ian Smith <smithi@nimnet.asn.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110115231949.M62193>