W dniu 3 kwietnia 2011 18:00 użytkownik drago01 <drago01(a)gmail.com> napisał:
2011/4/3 Michał Piotrowski <mkkp4x4(a)gmail.com>:
> W dniu 3 kwietnia 2011 12:54 użytkownik Lennart Poettering
> <mzerqung(a)0pointer.de> napisał:
>> On Sun, 03.04.11 13:10, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>>
>>> Hi,
>>>
>>> I can write to /run/user/michal in this way I can fill the entire free
>>> tmpfs space which is not good from my POV.
>>
>> Yupp, this is trivially fixable by placing another tmpfs on /run/user,
>> which can be done by installing a run-user.mount unit.
>>
>> We considered doing so by default, but stepped back a little, since we
>> didn't want to add another tmpfs to the mix, just like that. But yeah,
>> we probably should do that.
>
> I see no other way out here because tmpfs does not support quota.
>
> BTW. There still be a possibility to deadlock machine if you have a
> not limited /tmp on tmpfs. By default tmpfs can use a half of system
> memory size, so if you got a two user writable tmpfs file systems you
> can try to deadlock system.
You can try but that isn't a deadlock (if you can trigger a deadlock
that way you hit a kernel bug).
I did not mean deadlock in kernel synchronization mechanisms.
Let's say that we have a system with 2 GB of RAM and we got a /tmp
with tmpfs - if you don't configure size of this fs it will be 1 GB by
default. Next we got /run/user that also gets 1 GB by default. Both
dirs are user writable, so malicious user can fill them with data. Now
imagine that the system enters OOM situation. OOMK will not help here
- it can not delete files from tmpfs.
--
Best regards,
Michal
http://eventhorizon.pl/