W dniu 3 kwietnia 2011 18:00 użytkownik drago01 <drago01@xxxxxxxxx> napisał: > 2011/4/3 Michał Piotrowski <mkkp4x4@xxxxxxxxx>: >> W dniu 3 kwietnia 2011 12:54 użytkownik Lennart Poettering >> <mzerqung@xxxxxxxxxxx> napisał: >>> On Sun, 03.04.11 13:10, Michał Piotrowski (mkkp4x4@xxxxxxxxx) 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/ -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
