1. 29 Mar, 2009 4 commits
    • David Howells's avatar
      Annotate struct fs_struct's usage count restriction · 795e2fe0
      David Howells authored
      Annotate struct fs_struct's usage count to indicate the restrictions upon it.
      It may not be incremented, except by clone(CLONE_FS), as this affects the
      check in check_unsafe_exec() in fs/exec.c.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      795e2fe0
    • Hugh Dickins's avatar
      fix setuid sometimes wouldn't · 7c2c7d99
      Hugh Dickins authored
      check_unsafe_exec() also notes whether the fs_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>/cwd and /proc/<pid>/root lookups make transient
      use of get_fs_struct(), which also raises that sharing count.
      
      This might occasionally cause a setuid program not to change euid,
      in the same way as happened with files->count (check_unsafe_exec
      also looks at sighand->count, but /proc doesn't raise that one).
      
      We'd prefer exec not to unshare fs_struct: so fix this in procfs,
      replacing get_fs_struct() by get_fs_path(), which does path_get
      while still holding task_lock, instead of raising fs->count.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: stable@kernel.org
      ___
      
       fs/proc/base.c |   50 +++++++++++++++--------------------------------
       1 file changed, 16 insertions(+), 34 deletions(-)
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7c2c7d99
    • 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 36 commits