ext2 and ext3 block reservations can be bypassed
Elladan <[email protected]>:
Quoted 10 lines
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.txtstates that it's a security feature?If this is not a security feature,
Documentation/filesystems/ext2.txtneeds to be changed. Eg.,
Quoted 9 lines
"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.
Quoted 15 lines
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.txtReserved Space
--------------
Quoted 6 lines
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.
Quoted 6 lines
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: [email protected]
Any opinions expressed are solely my own.
Don't put /var/log on the same file system as /home, and don't grant access to /var/log to any normal userid.
This isn't 'new'.
mark
Quoted 17 lines · Jesse Pollard
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.
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 2 lines · Jesse Pollard
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
You are kidding. First of all, what kind of idiot has /var on root? What next - /var/spool/mail on the same filesystem, so that mailbombing root (or just a mail loop) could screw you over?
What's more, if you can't deal with overflowing /var/log, you are screwed - making syslogd to write something in log is _not_ hard.