lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 16 Dec 2013 11:14:36 -0200
From:	Carlos Maiolino <cmaiolino@...hat.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: [Bug 66951] New: filesystems should reserve inodes for root as
 they do disk space

Hi,

On Sat, Dec 14, 2013 at 12:09:19AM +0000, bugzilla-daemon@...zilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=66951
> 
>             Bug ID: 66951
>            Summary: filesystems should reserve inodes for root as they do
>                     disk space
>            Product: File System
>            Version: 2.5
>     Kernel Version: 3.11.10
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: enhancement
>           Priority: P1
>          Component: ext4
>           Assignee: fs_ext4@...nel-bugs.osdl.org
>           Reporter: kernelbugs@...nopolis.ca
>         Regression: No
> 
> I had a runaway non-root user process (Opera browser actually) exhaust all of
> the inodes on my / (root) filesystem (ext4) by creating millions of 10 to 50
> byte cache files in /home (which is not a separate partition on my system). 
> Linux & ext4 happily allowed this program to cripple the whole system until I
> figured out a) inodes were exhausted and b) what app was causing it and where
> they all were, and c) rm -rf them all.
> 
> We all know filesystems like ext2/3/4 reserve a (tunable) amount of space for
> root use only if a disk fills beyond a certain threshold.  I find it shocking
> that a similar mechanism does not exist for inodes.  Most *NIX geeks I know
> also can't believe it.  Do you find it shocking too?
> 
Yes, having an inode amount reserved for root might be good to avoid these
cases.

> One could argue I should have /home on a separate partition, but this is a
> non-solution because all it takes is one user-writable directory in / (root)
> such as /var/tmp.  Sure, then you could say /var should be a separate
> partition, but let's be realistic: 95%+ of systems out there will not have a
> separate /home or /var partition (let alone both).  Also, no distros by default
> create separate partitions for all of these.
> 
Sorry, but you're wrong here.

Almost all good system administrators knows the importance of keep directories
like /home and /var in different filesystems, for simply 2 reasons: 
- Keep system data separated from user data
- /var will store logs, and this might be HUGE in some cases.

And also, most distros I know of keeps /var and /home separated in their default
installations.

So, there is no excuse to keep /home and /var in different filesystems. Even if
you have just a single user, keep a separate /home filesystem is always
recommended.

> One could argue you should have your inode capacity be set so large it would be
> impossible to exhaust it before you run out of disk space.  That point is moot
> because a program could create 0 byte files, thus allowing exhaustion of inodes
> before free space (which would remain unchanged).  Besides, one should be
> allowed to tune their inodes at fs creation time to suit their usage habits as
> monitored over the years (such as looking at their usual NBPI and adding a 2 or
> 4X safety margin).
> 
I agree that change the inode capacity wouldn't make the system behave any
better.

> One could argue you could use quotas, but that seems unreasonable for the
> average guy (like myself) to do on their home desktop computer that only they
> use.
> 
Agreed indeed.

> Can ext2/3/4 and the kernel be modified to reserve a (tunable) number of inodes
> for root just as it does for disk space?
> 
I'm not sure how feasible it is or if is there any kind of job being done or
already done in this area, but is a good idea and I just added it to my TODO
list.

In the meantime, this isn't just a matter of how ext4 behaves regarding the
amount of inode, but looks like a BUG in your browser, or maybe you're accessing
a site which creates thousands of inodes?

-- 
Carlos
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ