Description of problem:
A normal user is able to create a file in /run/user/<user number> that completely consumes all of the space. Thus when system tasks need to allocate space in tmpfs, they cancel.
Version-Release number of selected component (if applicable):
Fedora 18 Alpha RC3
How reproducible:
as a normal user:
[Me@tower20 /]$ dd if=/dev/zero of=/run/user/1000/test bs=1024 count=50000000000
dd: writing '/run/user/1000/test': No space left on device
2007521+0 records in
2007520+0 records out
2055700480 bytes (2.1 GB) copied, 109.335 s, 18.8 MB/s
Steps to Reproduce:
1. log into a terminal screen as a normal user
2. run the dd command
3. try mounting filesystem afterwards, it cancels with no room left on device.
Actual results:
All tmpfs space in /run is consumed
Expected results:
I really don't think a user without any privileges should be able to bring a system to it's knees with just one simple command.
Additional info:
Comment 1Lennart Poettering
2012-09-14 09:09:38 UTC
Well, that's a general problem that tmpfs knows no quota right now, and is not specific to /run, but is also intrinsic to /dev/shm an /tmp which are publicly writable tmpfs.
We really need quota on tmpfs, and this has been requested before. Reassigning to kernel.
There have been patches for this already:
https://lwn.net/Articles/466376/
This patch introducing RLIMIT_TMPFSQUOTA makes a ton of sense to me, but I am fine with any other solution too.