Re: shmget with SHM_HUGETLB flag: Operation not permitted

From: William Lee Irwin III (wli_at_holomorphy.com)
Date: 02/29/04

  • Next message: Peter Williams: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler" 
    Date:	Sun, 29 Feb 2004 14:31:53 -0800
To: Jochen Roemling <jochen@roemling.net>

    William Lee Irwin III wrote:
    >> It's capable(CAP_IPC_LOCK) || in_group_p(0), not current->uid == 0.
    >> It will barf if you ask for more than either one of those limits. It
    >> will also barf if you ask for an amount not a multiple of the hugepage
    >> size. Please show the test program's code and strace the test program
    >> to determine what response it's getting.

    On Sun, Feb 29, 2004 at 10:37:38PM +0100, Jochen Roemling wrote:
    > What do I have to do to make this pgm run as an ordinary user with a
    > stock kernel?

    Locked memory is a privileged resource, so you do have to do something
    to authenticate lest any user be able to consume all memory on your
    system with no possibility of paging it. Examples of what to do to
    acquire locked memory specifically for hugetlb shm segments in mainline:

    (a) give the user gid 0 as a primary or supplementary group
    (b) grant the capability -- yes, it can be done (and is being done in
            practice elsewhere), something is going wrong on your end I
            haven't been able to diagnose.
    (c) make requests from a shmget() proxy daemon where you make requests
            over a socket and it hands back shm segment ID's that have had
            their uid's/perms set to the end user. Once shmget() is done,
            shmat() uses normal shm permissions checks.
    (d) use a setuid root shmget() helper app.
    (e) launch as root, then retain capabilities
    (f) launch as root and shmget before dropping privs

    (e) and (f) are probably not options in your case. I can't predict
    what's going to be desirable on your end in general. You will have to
    jump through a hoop of some kind, though, and be glad you do, since
    otherwise unbounded amounts of locked memory requested by arbitrary
    users could cripple the system's performance or worse.

    -- wli
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Peter Williams: "Re: [RFC][PATCH] O(1) Entitlement Based Scheduler"

    Relevant Pages