1. 04 11月, 2006 1 次提交
    • P
      [PATCH] Fix ipc entries removal · c7e12b83
      Pavel Emelianov 提交于
      Fix two issuses related to ipc_ids->entries freeing.
      
      1. When freeing ipc namespace we need to free entries allocated
         with ipc_init_ids().
      
      2. When removing old entries in grow_ary() ipc_rcu_putref()
         may be called on entries set to &ids->nullentry earlier in
         ipc_init_ids().
         This is almost impossible without namespaces, but with
         them this situation becomes possible.
      
      Found during OpenVZ testing after obvious leaks in beancounters.
      Signed-off-by: NPavel Emelianov <xemul@openvz.org>
      Cc: Kirill Korotaev <dev@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c7e12b83
  2. 02 10月, 2006 2 次提交
  3. 01 7月, 2006 1 次提交
  4. 20 6月, 2006 1 次提交
    • L
      [PATCH] update of IPC audit record cleanup · ac03221a
      Linda Knippers 提交于
      The following patch addresses most of the issues with the IPC_SET_PERM
      records as described in:
      https://www.redhat.com/archives/linux-audit/2006-May/msg00010.html
      and addresses the comments I received on the record field names.
      
      To summarize, I made the following changes:
      
      1. Changed sys_msgctl() and semctl_down() so that an IPC_SET_PERM
         record is emitted in the failure case as well as the success case.
         This matches the behavior in sys_shmctl().  I could simplify the
         code in sys_msgctl() and semctl_down() slightly but it would mean
         that in some error cases we could get an IPC_SET_PERM record
         without an IPC record and that seemed odd.
      
      2. No change to the IPC record type, given no feedback on the backward
         compatibility question.
      
      3. Removed the qbytes field from the IPC record.  It wasn't being
         set and when audit_ipc_obj() is called from ipcperms(), the
         information isn't available.  If we want the information in the IPC
         record, more extensive changes will be necessary.  Since it only
         applies to message queues and it isn't really permission related, it
         doesn't seem worth it.
      
      4. Removed the obj field from the IPC_SET_PERM record.  This means that
         the kern_ipc_perm argument is no longer needed.
      
      5. Removed the spaces and renamed the IPC_SET_PERM field names.  Replaced iuid and
         igid fields with ouid and ogid in the IPC record.
      
      I tested this with the lspp.22 kernel on an x86_64 box.  I believe it
      applies cleanly on the latest kernel.
      
      -- ljk
      Signed-off-by: NLinda Knippers <linda.knippers@hp.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ac03221a
  5. 01 5月, 2006 1 次提交
    • S
      [PATCH] Rework of IPC auditing · 073115d6
      Steve Grubb 提交于
      1) The audit_ipc_perms() function has been split into two different
      functions:
              - audit_ipc_obj()
              - audit_ipc_set_perm()
      
      There's a key shift here...  The audit_ipc_obj() collects the uid, gid,
      mode, and SElinux context label of the current ipc object.  This
      audit_ipc_obj() hook is now found in several places.  Most notably, it
      is hooked in ipcperms(), which is called in various places around the
      ipc code permforming a MAC check.  Additionally there are several places
      where *checkid() is used to validate that an operation is being
      performed on a valid object while not necessarily having a nearby
      ipcperms() call.  In these locations, audit_ipc_obj() is called to
      ensure that the information is captured by the audit system.
      
      The audit_set_new_perm() function is called any time the permissions on
      the ipc object changes.  In this case, the NEW permissions are recorded
      (and note that an audit_ipc_obj() call exists just a few lines before
      each instance).
      
      2) Support for an AUDIT_IPC_SET_PERM audit message type.  This allows
      for separate auxiliary audit records for normal operations on an IPC
      object and permissions changes.  Note that the same struct
      audit_aux_data_ipcctl is used and populated, however there are separate
      audit_log_format statements based on the type of the message.  Finally,
      the AUDIT_IPC block of code in audit_free_aux() was extended to handle
      aux messages of this new type.  No more mem leaks I hope ;-)
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      073115d6
  6. 27 3月, 2006 2 次提交
  7. 21 3月, 2006 1 次提交
    • D
      [PATCH] Capture selinux subject/object context information. · 8c8570fb
      Dustin Kirkland 提交于
      This patch extends existing audit records with subject/object context
      information. Audit records associated with filesystem inodes, ipc, and
      tasks now contain SELinux label information in the field "subj" if the
      item is performing the action, or in "obj" if the item is the receiver
      of an action.
      
      These labels are collected via hooks in SELinux and appended to the
      appropriate record in the audit code.
      
      This additional information is required for Common Criteria Labeled
      Security Protection Profile (LSPP).
      
      [AV: fixed kmalloc flags use]
      [folded leak fixes]
      [folded cleanup from akpm (kfree(NULL)]
      [folded audit_inode_context() leak fix]
      [folded akpm's fix for audit_ipc_perm() definition in case of !CONFIG_AUDIT]
      Signed-off-by: NDustin Kirkland <dustin.kirkland@us.ibm.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8c8570fb
  8. 15 1月, 2006 1 次提交
  9. 12 1月, 2006 1 次提交
  10. 25 12月, 2005 2 次提交
  11. 08 9月, 2005 1 次提交
  12. 06 8月, 2005 1 次提交
  13. 24 6月, 2005 1 次提交
  14. 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