[lkml]   [2011]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] tmpfs: support user quotas
    (11/7/2011 6:30 AM), Lennart Poettering wrote:
    > On Mon, 07.11.11 13:58, Alan Cox ( wrote:
    >>> Right, rlimit approach guarantees a simple way of dealing with users
    >>> across all tmpfs instances.
    >> Which is almost certainly not what you want to happen. Think about direct
    >> rendering.
    > I don't see what direct rendering has to do with closing the security
    > hole that /dev/shm currently is.
    >> For simple stuff tmpfs already supports size/nr_blocks/nr_inodes mount
    >> options so you can mount private resource constrained tmpfs objects
    >> already without kernel changes. No rlimit hacks needed - and rlimit is
    >> the wrong API anyway.
    > Uh? I am pretty sure we don't want to mount a private tmpfs for each
    > user in /dev/shm and /tmp. If you have 500 users you'd have 500 tmpfs on
    > /tmp and on /dev/shm. Despite that without some ugly namespace hackery
    > you couldn't make them all appear in /tmp as /dev/shm without
    > subdirectories. Don't forget that /dev/shm and /tmp are an established
    > userspace API.
    > Resource limits are exactly the API that makes sense here, because:
    > a) we only want one tmpfs on /tmp, and one tmpfs on /dev/shm, not 500 on
    > each for each user

    Ok, seems fair.

    > b) we cannot move /dev/shm, /tmp around without breaking userspace
    > massively


    > c) we want a global limit across all tmpfs file systems for each user

    Why? Is there any benefit this?

    > d) we don't want to have to upload the quota database into each tmpfs at
    > mount time.
    > And hence: a per user RLIMIT is exactly the minimal solution we want
    > here.

    If you want per-user limitation, RLIMIT is bad idea. RLIMIT is only inherited
    by fork. So, The api semantics clearly mismatch your usecase.

    Instead, I suggest to implement new sysfs knob.

    Thank you.

     \ /
      Last update: 2011-11-07 23:17    [W:0.025 / U:12.916 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site