1. 19 10月, 2007 2 次提交
    • D
      whitespace fixes: capability syscalls · 314f70fd
      Daniel Walker 提交于
      Large chunks of 5 spaces instead of tabs.
      Signed-off-by: NDaniel Walker <dwalker@mvista.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      314f70fd
    • A
      V3 file capabilities: alter behavior of cap_setpcap · 72c2d582
      Andrew Morgan 提交于
      The non-filesystem capability meaning of CAP_SETPCAP is that a process, p1,
      can change the capabilities of another process, p2.  This is not the
      meaning that was intended for this capability at all, and this
      implementation came about purely because, without filesystem capabilities,
      there was no way to use capabilities without one process bestowing them on
      another.
      
      Since we now have a filesystem support for capabilities we can fix the
      implementation of CAP_SETPCAP.
      
      The most significant thing about this change is that, with it in effect, no
      process can set the capabilities of another process.
      
      The capabilities of a program are set via the capability convolution
      rules:
      
         pI(post-exec) = pI(pre-exec)
         pP(post-exec) = (X(aka cap_bset) & fP) | (pI(post-exec) & fI)
         pE(post-exec) = fE ? pP(post-exec) : 0
      
      at exec() time.  As such, the only influence the pre-exec() program can
      have on the post-exec() program's capabilities are through the pI
      capability set.
      
      The correct implementation for CAP_SETPCAP (and that enabled by this patch)
      is that it can be used to add extra pI capabilities to the current process
      - to be picked up by subsequent exec()s when the above convolution rules
      are applied.
      
      Here is how it works:
      
      Let's say we have a process, p. It has capability sets, pE, pP and pI.
      Generally, p, can change the value of its own pI to pI' where
      
         (pI' & ~pI) & ~pP = 0.
      
      That is, the only new things in pI' that were not present in pI need to
      be present in pP.
      
      The role of CAP_SETPCAP is basically to permit changes to pI beyond
      the above:
      
         if (pE & CAP_SETPCAP) {
            pI' = anything; /* ie., even (pI' & ~pI) & ~pP != 0  */
         }
      
      This capability is useful for things like login, which (say, via
      pam_cap) might want to raise certain inheritable capabilities for use
      by the children of the logged-in user's shell, but those capabilities
      are not useful to or needed by the login program itself.
      
      One such use might be to limit who can run ping. You set the
      capabilities of the 'ping' program to be "= cap_net_raw+i", and then
      only shells that have (pI & CAP_NET_RAW) will be able to run
      it. Without CAP_SETPCAP implemented as described above, login(pam_cap)
      would have to also have (pP & CAP_NET_RAW) in order to raise this
      capability and pass it on through the inheritable set.
      Signed-off-by: NAndrew Morgan <morgan@kernel.org>
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Casey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72c2d582
  2. 17 10月, 2007 1 次提交
  3. 13 2月, 2007 1 次提交
  4. 30 9月, 2006 1 次提交
  5. 04 7月, 2006 1 次提交
  6. 26 3月, 2006 1 次提交
  7. 12 1月, 2006 1 次提交
  8. 28 7月, 2005 1 次提交
  9. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4