Skip site navigation (1)Skip section navigation (2)
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>