[lkml]   [2004]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: disable-cap-mlock
    Andrew Morton <> wrote:
    > Rumour has it that the more exhasperated among us are brewing up a patch to
    > login.c which will allow capabilities to be retained after the setuid.

    So I spent a few hours getting pam_cap to work, and indeed it is now doing the
    right thing. But the kernel is not.

    It turns out that the whole "drop capabilities and then run something"
    thing does not work in either 2.4 or 2.6. And hasn't done since forever.
    What we have in there is no more useful than suser().

    You can do prctl(PR_SET_KEEPCAPS, 1) so that permitted caps are retained
    across setuid(). And after the setuid() you can raise effective caps
    again. So that's workable, although pretty sad - it requires that su and
    login be patched to run the prctl and to re-raise effective caps.

    But the two showstoppers are:

    1) capabilities are unconditionally nuked across execve() unless you're
    root (cap_bprm_set_security())

    2) the kernel unconditionally removes CAP_SETPCAP in dummy_capget() so
    it is not possible for even a root-owned, otherwise-fully-capable task
    to raise capabilities on another task. Period.

    I must say that I'm fairly disappointed that we developed and merged all
    that fancy security stuff but nobody ever bothered to fix up the existing
    simple capability code.

    Particularly as, apparently, the new security stuff STILL cannot solve the
    extremely simple Oracle-wants-CAP_IPC_LOCK requirement.

    Chris has proposed a little patch which will enable the retention of caps
    across execve. I'd be interested in knowing why we _ever_ dropped caps
    across execve? I thing we should run with Chris's patch - but the new
    functionality should of course only be enabled by some admin-settable knob.

    I'm looking at securebits.h and wondering why that exists - there's no code
    in-kernel to set the thing, although it is exported to modules. Perhaps
    securebits should be exposed in /proc and used to enable
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.020 / U:0.684 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site