From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [PATCH] proc: make proc_fd_permission() thread-friendly Date: Mon, 26 Aug 2013 12:10:16 -0700 Message-ID: <8738pwp8tj.fsf@xmission.com> References: <20130824212432.GA9299@1wt.eu> <20130825052317.GZ27005@ZenIV.linux.org.uk> <20130825065039.GB9299@1wt.eu> <20130825194844.GA16717@redhat.com> <20130826153301.GA15890@redhat.com> <20130826163704.GA21763@redhat.com> <20130826175441.GA28856@redhat.com> <87ioyspaju.fsf@xmission.com> <20130826184631.GA30917@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Andrew Morton , Willy Tarreau , Al Viro , Andy Lutomirski , Ingo Molnar , Linux Kernel Mailing List , Linux FS Devel , Brad Spengler , Linus Torvalds To: Oleg Nesterov Return-path: In-Reply-To: <20130826184631.GA30917@redhat.com> (Oleg Nesterov's message of "Mon, 26 Aug 2013 20:46:31 +0200") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Oleg Nesterov writes: > On 08/26, Eric W. Biederman wrote: >> >> Oleg Nesterov writes: >> >> > proc_fd_permission() says "process can still access /proc/self/fd >> > after it has executed a setuid()", but the "task_pid() = proc_pid() >> > check only helps if the task is group leader, /proc/self points to >> > /proc/leader-pid. >> > >> > Change this check to use task_tgid() so that the whole process can >> > access /proc/self/fd. >> >> There is at least a semantic goofiness here. >> >> There is /proc//fd and /proc//task//fd, and the same >> permission check is used by both. > > Yes, and we have /proc// which includes fd as well. > >> We might just want to have a /proc/thread symlink as well so people >> don't have this issue. > > Yes! I agree. > > In particular, from the changelog: > > Note: CLONE_THREAD doesn't require CLONE_FILES so task->files can > differ, > > so /proc/self/fd doesn't necessarily mean current->files, this can confuse > the application. > > And I also assume that you agree with this change ;) I don't disagree. Comparing tgid to pids is goofy and my brain is elsewhere so I have no thought through the implications. Actually thinking I think the check should really be. In which case we are comparing what we really care about. int proc_fd_permission(struct inode *inode, int mask) { int rv = generic_permission(inode, mask); if (rv == 0) return 0; rcu_read_lock(); struct task *task = pid_task(proc_pid(inode)); if (task && (current->files == task->files)) rv = 0; rcu_read_unlock(); return rv; } Eric