1. 29 Mar, 2009 2 commits
    • Hugh Dickins's avatar
      fix setuid sometimes doesn't · e426b64c
      Hugh Dickins authored
      Joe Malicki reports that setuid sometimes doesn't: very rarely,
      a setuid root program does not get root euid; and, by the way,
      they have a health check running lsof every few minutes.
      
      Right, check_unsafe_exec() notes whether the files_struct is being
      shared by more threads than will get killed by the exec, and if so
      sets LSM_UNSAFE_SHARE to make bprm_set_creds() careful about euid.
      But /proc/<pid>/fd and /proc/<pid>/fdinfo lookups make transient
      use of get_files_struct(), which also raises that sharing count.
      
      There's a rather simple fix for this: exec's check on files->count
      has been redundant ever since 2.6.1 made it unshare_files() (except
      while compat_do_execve() omitted to do so) - just remove that check.
      
      [Note to -stable: this patch will not apply before 2.6.29: earlier
      releases should just remove the files->count line from unsafe_exec().]
      Reported-by: default avatarJoe Malicki <jmalicki@metacarta.com>
      Narrowed-down-by: default avatarMichael Itz <mitz@metacarta.com>
      Tested-by: default avatarJoe Malicki <jmalicki@metacarta.com>
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e426b64c
    • Hugh Dickins's avatar
      compat_do_execve should unshare_files · 53e9309e
      Hugh Dickins authored
      2.6.26's commit fd8328be
      "sanitize handling of shared descriptor tables in failing execve()"
      moved the unshare_files() from flush_old_exec() and several binfmts
      to the head of do_execve(); but forgot to make the same change to
      compat_do_execve(), leaving a CLONE_FILES files_struct shared across
      exec from a 32-bit process on a 64-bit kernel.
      
      It's arguable whether the files_struct really ought to be unshared
      across exec; but 2.6.1 made that so to stop the loading binary's fd
      leaking into other threads, and a 32-bit process on a 64-bit kernel
      ought to behave in the same way as 32 on 32 and 64 on 64.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      53e9309e
  2. 28 Mar, 2009 38 commits