1. 01 7月, 2006 1 次提交
  2. 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
  3. 18 4月, 2006 1 次提交
  4. 01 4月, 2006 1 次提交
  5. 27 3月, 2006 1 次提交
  6. 15 1月, 2006 1 次提交
  7. 12 1月, 2006 1 次提交
  8. 07 11月, 2005 1 次提交
  9. 08 9月, 2005 1 次提交
  10. 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