Bug 857297

Summary: We need quota on tmpfs, to fix DoS vulnerabilities in /dev/shm, /tmp, /run
Product: [Fedora] Fedora Reporter: Daniel Belton <danielbelton>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: gansalmon, hannsj_uhl, itamar, johannbg, jonathan, kernel-maint, lnykryn, lpoetter, madhu.chinakonda, metherid, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-14 10:13:26 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Daniel Belton 2012-09-13 23:56:00 EDT
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 1 Lennart Poettering 2012-09-14 05:09:38 EDT
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.
Comment 2 Josh Boyer 2012-09-14 10:13:26 EDT

*** This bug has been marked as a duplicate of bug 693253 ***