Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755854AbZC1XV7 (ORCPT ); Sat, 28 Mar 2009 19:21:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755016AbZC1XVs (ORCPT ); Sat, 28 Mar 2009 19:21:48 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:35561 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752937AbZC1XVr (ORCPT ); Sat, 28 Mar 2009 19:21:47 -0400 Date: Sat, 28 Mar 2009 23:20:19 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.anvils To: Al Viro cc: Linus Torvalds , Andrew Morton , Joe Malicki , Michael Itz , Kenneth Baker , Chris Wright , David Howells , Alexey Dobriyan , Oleg Nesterov , Greg Kroah-Hartman , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/4] fix setuid sometimes doesn't In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3436 Lines: 98 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//fd and /proc//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: Joe Malicki Narrowed-down-by: Michael Itz Tested-by: Joe Malicki Signed-off-by: Hugh Dickins Cc: stable@kernel.org --- fs/compat.c | 2 +- fs/exec.c | 10 +++------- fs/internal.h | 2 +- 3 files changed, 5 insertions(+), 9 deletions(-) --- 2.6.29/fs/compat.c 2009-03-23 23:12:14.000000000 +0000 +++ linux/fs/compat.c 2009-03-28 18:06:02.000000000 +0000 @@ -1412,7 +1412,7 @@ int compat_do_execve(char * filename, bprm->cred = prepare_exec_creds(); if (!bprm->cred) goto out_unlock; - check_unsafe_exec(bprm, current->files); + check_unsafe_exec(bprm); file = open_exec(filename); retval = PTR_ERR(file); --- 2.6.29/fs/exec.c 2009-03-23 23:12:14.000000000 +0000 +++ linux/fs/exec.c 2009-03-28 18:06:02.000000000 +0000 @@ -1049,28 +1049,24 @@ EXPORT_SYMBOL(install_exec_creds); * - the caller must hold current->cred_exec_mutex to protect against * PTRACE_ATTACH */ -void check_unsafe_exec(struct linux_binprm *bprm, struct files_struct *files) +void check_unsafe_exec(struct linux_binprm *bprm) { struct task_struct *p = current, *t; unsigned long flags; - unsigned n_fs, n_files, n_sighand; + unsigned n_fs, n_sighand; bprm->unsafe = tracehook_unsafe_exec(p); n_fs = 1; - n_files = 1; n_sighand = 1; lock_task_sighand(p, &flags); for (t = next_thread(p); t != p; t = next_thread(t)) { if (t->fs == p->fs) n_fs++; - if (t->files == files) - n_files++; n_sighand++; } if (atomic_read(&p->fs->count) > n_fs || - atomic_read(&p->files->count) > n_files || atomic_read(&p->sighand->count) > n_sighand) bprm->unsafe |= LSM_UNSAFE_SHARE; @@ -1289,7 +1285,7 @@ int do_execve(char * filename, bprm->cred = prepare_exec_creds(); if (!bprm->cred) goto out_unlock; - check_unsafe_exec(bprm, displaced); + check_unsafe_exec(bprm); file = open_exec(filename); retval = PTR_ERR(file); --- 2.6.29/fs/internal.h 2009-03-23 23:12:14.000000000 +0000 +++ linux/fs/internal.h 2009-03-28 18:06:02.000000000 +0000 @@ -43,7 +43,7 @@ extern void __init chrdev_init(void); /* * exec.c */ -extern void check_unsafe_exec(struct linux_binprm *, struct files_struct *); +extern void check_unsafe_exec(struct linux_binprm *); /* * namespace.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/