public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: elladan@eskimo.com, Christoph Hellwig <hch@infradead.org>,
	Elladan <elladan@eskimo.com>,
	Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] ext2 and ext3 block reservations can be bypassed
Date: Tue, 14 May 2002 12:53:47 -0500 (CDT)	[thread overview]
Message-ID: <200205141753.MAA70930@tomcat.admin.navo.hpc.mil> (raw)

Elladan <elladan@eskimo.com>:
> I went to google and attempted to find information about the root
> reserve space for ext2, as a user wondering about the feature would.  I
> couldn't find any documentation that states it's purely a fragmentation
> and convenience feature.  I did, however, find documents stating
> otherwise.  Note how even Documentation/filesystems/ext2.txt states that
> it's a security feature?
> 
> If this is not a security feature, Documentation/filesystems/ext2.txt
> needs to be changed.  Eg., 
> 
> "In ext2, there is a mechanism for reserving a certain number of blocks
> for a particular user (normally the super-user).  This is intended to
> keep the filesystem from filling up entirely, which helps combat
> fragmentation.  The super-user may still use this space.  Note that this
> is not a security feature, and is only provided for convenience -
> various methods exist where a user may circumvent this reservation and
> use the space if they so wish.  Quotas or separate filesystems should be
> used if reliable space limits are needed."
> 

If the root file system is ext2, it does become a security issue since
currently active logs will continue to record log entries until the
filesystem is absolutly filled. I should say, if the log device fills up,
since the log directory is usually /var/log, or /var/adm. Some logs show
up in etc, but that really depends on the configuration. It IS usefull if the
filesystem is "full" due to attacks - daemons tend to terminate themselves,
and their log entry indicates what the problem was. If it is an attack, then
it's a security issue.

The only reason it helps fragmentation (subject to actual implementor
statements) is that the filesystem code will use every scavanged block
possible under saturation. When the filesystem gets cleand up later,
these excessively fragmented files will remain, and continue to cause
access delays.

Naturally, deleting (or backup/restore) the file(s) cleans up the fragmentation.

> 
> 1. http://web.mit.edu/tytso/www/linux/ext2intro.html
> 
> Design and Implementation of the Second Extended Filesystem
> 
> [....] Ext2fs reserves some blocks for the super user (root). Normally,
> 5% of the blocks are reserved. This allows the administrator to recover
> easily from situations where user processes fill up filesystems.
> 
> 
> 2. Documentation/filesystems/ext2.txt
> 
> Reserved Space
> --------------
> 
> In ext2, there is a mechanism for reserving a certain number of blocks
> for a particular user (normally the super-user).  This is intended to
> allow for the system to continue functioning even if non-priveleged
> users fill up all the space available to them (this is independent of
> filesystem quotas).  It also keeps the filesystem from filling up
> entirely which helps combat fragmentation.

True, but this is a side effect caused by stopping user allocations.
 
> 3. Note what mke2fs prints:
> 
> 3275 blocks (5.00%) reserved for the super user
> 
> It does not say "reserved to combat fragmentation"
> 

It shouldn't have to. This is a tuneable value, and can be set to 0.
(tune2fs).

The "super user" is also an option. It defaults to the user "root", but
can be specified to be a user OR a group by tune2fs (-g option for group,
-u option for user).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

             reply	other threads:[~2002-05-14 17:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-14 17:53 Jesse Pollard [this message]
2002-05-14 18:23 ` [RFC] ext2 and ext3 block reservations can be bypassed Mark Mielke
2002-05-14 19:11 ` Alexander Viro
  -- strict thread matches above, loose matches on Subject: below --
2002-05-14 19:29 Jesse Pollard
2002-05-14 18:54 Jesse Pollard
2002-05-14 19:04 ` Alexander Viro
2002-05-14 19:55 ` Mark Mielke
2002-05-14 18:07 Jesse Pollard
2002-05-14 18:00 Jesse Pollard
     [not found] <791836807@toto.iv>
2002-05-12 22:04 ` Peter Chubb
2002-05-12 22:53   ` Alexander Viro
2002-05-13  4:22     ` Kasper Dupont
2002-05-13  4:51       ` Elladan
2002-05-12 16:23 Kasper Dupont
2002-05-12 16:42 ` Jakob Østergaard
2002-05-12 17:34   ` Elladan
2002-05-12 18:15     ` Alexander Viro
2002-05-12 18:37       ` Elladan
2002-05-12 19:02         ` Jakob Østergaard
2002-05-12 19:04           ` Mark Mielke
2002-05-13 17:09         ` Horst von Brand
2002-05-13 17:52           ` Elladan
2002-05-13 17:57             ` Christoph Hellwig
2002-05-14 16:22               ` Elladan
2002-05-14 16:55                 ` Mark Mielke
2002-05-14 17:47                   ` Elladan
2002-05-14 18:51                     ` Kasper Dupont
2002-05-15 19:48                 ` Pavel Machek
2002-05-15 20:29                   ` Alan Cox
2002-05-14 15:40           ` Kasper Dupont
2002-05-14 15:56             ` Mark Mielke
2002-05-14 18:25               ` Kasper Dupont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200205141753.MAA70930@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=elladan@eskimo.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox