Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotas for tmpfs
The second version of the plumber's
wish list for Linux included a request for support for usage quotas on
the tmpfs filesystem. Current kernels have no such support, making it easy
for local users to execute denial-of-service attacks by filling up
/tmp or /dev/shm. Davidlohr Bueso answered that call
with a patch providing that support. But
it turns out that there is a disagreement over how tmpfs use limits should be
managed.
Davidlohr's patch does not actually implement quotas; instead, it adds a new resource limit (RLIMIT_TMPFSQUOTA) controlling how much space a user can occupy on all mounted tmpfs systems. This is the approach requested in the wish list; it has some appeal because tmpfs is not a persistent filesystem. Normal filesystem implementations store quotas on the filesystem itself, but tmpfs cannot do that. So use of quotas would require that user space, in some fashion, reload the quota database on every boot (or, depending on the implementation, for every tmpfs mount). Resource limits look like a simpler situation. Even so, there is opposition to the resource limit approach. Developers would rather see tmpfs behave like other filesystems. More to the point, perhaps, users and applications have some clue, some of the time, on how to respond to "quota exceeded" errors. Blown resource limits, instead, are on less solid ground. As Alan Cox pointed out, loading the quotas need not be a big problem; it could be as simple as a mount option setting a default quota for all users. In the end, it seems unlikely that an implementation based on anything other than disk quotas will be merged, so this patch will need to be reworked. (Log in to post comments)
Quotas for tmpfs Posted Nov 10, 2011 23:13 UTC (Thu) by RogerOdle (subscriber, #60791) [Link]
I have not used quotas in a long time since I have mostly used Linux on standalone workstations for engineering purposes. As I recall, the quota mechanism is a per-user system. What may be preferable is to group ordinary users together as far as the tmp file system is concerned. Say allow all ordinary users to use up to 75% of a tmp file space reserving 25% for system use and servers.
Alternatively, the system might be setup so that system and server operations use tmp file space that is off limits to ordinary users so that user applications can not exhaust the resources required by the system. Note that it may be a matter of configuration for a particular server to use the system tmp space or the user tmp space.
In any case, it is the intention to protect the integrity of the system from user space applications.
Quotas for tmpfs Posted Nov 11, 2011 16:50 UTC (Fri) by nix (subscriber, #2304) [Link] What may be preferable is to group ordinary users together as far as the tmp file system is concerned.You mean, group quotas, which have existed for as long as user quotas?
Quotas for tmpfs Posted Nov 12, 2011 20:52 UTC (Sat) by Tobu (subscriber, #24111) [Link] Or ballooning, like ext's policy of keeping the last 5% available for only root.
Quotas for tmpfs Posted Nov 13, 2011 1:26 UTC (Sun) by giraffedata (subscriber, #1954) [Link] What's appropriate for limiting tmpfs depends entirely on the specific problems you're trying to avoid, which we haven't established.The classic Unix system which is used by multiple persons, each with a unique userid, are very rare now. On a system like that, a per-userid quota would make sense, though, to prevent a malicious user from denying service to others. But multiuser systems today typically have multiple persons acting through the same userid (which owns a server process). On those, per-userid quota isn't much use. Besides malicious attack, another great use of tmpfs space limitation is to limit the risk of an inadvertent runaway process. A per-process resource limit is a sensible way to do that. Reserving space for root is a particularly ham-handed way protect system integrity, since root isn't all that special. It often uses space on behalf of unprivileged unimportant users, for one thing. And other userids are often critical to the system (there's no point in all those system management things running if the web server can't, after all). There already is a great facility for protecting a process from another process' indiscriminate use of tmpfs space: make a tmpfs filesystem just for him. Any serious program ought either to respect the TMPDIR environment variable or provide some other means of directing the location of temporary files.
Quotas for tmpfs Posted Nov 13, 2011 1:09 UTC (Sun) by giraffedata (subscriber, #1954) [Link] The systems on which I use filesystem space quotas have the quotas in an arbitrary file you identify when you turn on quota checking. There's no need for this file to be in the quota-checked filesystem. Of course, these systems are ca. 2004. Has that changed?
|
|||||||||||||