lkml.org 
[lkml]   [2011]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 (alan@lxorguk.ukuu.org.uk) 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

    agreed.

    >
    > 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.023 / U:0.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site