Date: Mon, 18 Feb 2008 11:34:40 -0600 From: Scott Lambert <lambert@lambertfam.org> To: freebsd-fs@freebsd.org, freebsd-security@freebsd.org, FreeBSD-bugs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to take down a system to the point of requiring a newfs with one line of C (userland) Message-ID: <20080218173439.GA40800@sysmon.tcworks.net> In-Reply-To: <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com> References: <47B90868.7000900@electron-tube.net> <291ddc4f0802180714g3d326626v9d9b767a61232cec@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 18, 2008 at 09:14:30AM -0600, Daniel Corrigan wrote: > Since this was released to a public mailing list, I can only assume > some less than nice user will attempt this. The only top level file > system I have that can be written to by normal users is /tmp > > Should clear_tmp_enable="YES" in /etc/rc.conf prevent this from > causing harm? Probably not. But an inode quota might, if your users can deal with having less than 10000 inodes - (what is supposed to be in the root of such file systems). It would at least make it more difficult for one rogue user to hurt you. Perhaps an /usr/local/etc/rc.d script could look for problems such as this in the stop process. Or one could simply remount the /tmp disk to /data and make a symlink from /tmp to /data/tmp. It seems like there should be several possible workarounds. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080218173439.GA40800>