On Tue, May 10, 2011 at 5:10 PM, Lennart Poettering
<mzerqung@xxxxxxxxxxx> wrote:
> On Tue, 10.05.11 02:17, Miloslav TrmaÄ (mitr@xxxxxxxx) wrote:
>
>> On Tue, May 10, 2011 at 1:33 AM, Lennart Poettering
>> <mzerqung@xxxxxxxxxxx> wrote:
>> > Countermeasures for the /dev/shm issue? I don't know of any. tmpfs
>> > doesn't do quota. That's the key problem here.
>>
>> mount options, file permissions, SELinux. ÂPerhaps not something that
>> you'd want to do on a general-purpose desktop, but quite reasonable
>> for a single-purpose server.
>
> No. mount options, file permissions, SELinux don't allow you to fix the
> quota issue with /dev/shm.
There is no "quota issue". There is a DoS threat. Mounting with
size=X, where X is large enough to accommodate the applications I care
about, and small enough that the system won't run out of memory and
swap space, is a countermeasure to the DoS.[1] Using file permissions
or SELinux to only allow users I care about to use /dev/shm is a
countermeasure to DoS by other users.
Quota is also (only) a way to avoid the DoS[2]. Sure, it's the most
generally applicable one.
Really, all I wanted to do in this subthread is to support the request
for a release note.
Mirek
[1] How many users of Fedora would notice if the /dev/shm tmpfs was
limited to 512MB by default? And no, I'm _not_ advocating making this
the default configuration.
[2] ... like many DoS countermeasures, by intentionally adding a
different, more predictable, kind of DoS, always denying users the
service of allocating /dev/shm over a certain limit. Making a system
ideally DoS-proof is probably impossible (after all there's little
outside difference between a DoS and an user that legitimately needs
to use 101% of a resource); nevertheless if users are willing to
sacrifice capacity or features, they can often get some level of DoS
resistance.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
