Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3002824imu; Sun, 9 Dec 2018 14:50:17 -0800 (PST) X-Google-Smtp-Source: AFSGD/XSWCjP1KThF7h3Nr56vhXeIyXkNjneo15/AXZldWgu8v2U/tS+rnEUX8tefL1/VXMlZBEa X-Received: by 2002:a63:f901:: with SMTP id h1mr877763pgi.154.1544395817142; Sun, 09 Dec 2018 14:50:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544395817; cv=none; d=google.com; s=arc-20160816; b=ijFsGjlBy4yNkbGWPPiszsLPojiBFHvmyhWG4G8OAFRlTfNKAATovsARC6ceWSEtwU RRzatLLo4Kd2mTLCNn355LEsonu54A6HHdHDEoTnmDKOMRp0Nek49YX/EuchfC/bVIf6 b0Sapdg0eYg9Pzlg7mqYF/+f0zVcFOWlYdcPGSqYtAW9V+J3ucrEmGtI/b+ALxBFPo5x 1d9cwCFphd8ODuLzflk4Hle54cSdaoVilfd/HCW0s4cGwt1iu5lOsAW5s2curlsNckQE B7mfrymWGJV72dnkH1fHSxROadtreg+qAJl6vLw5vo+4fpkYU0ukuNMLTkkbJ56bKfO8 ycOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=TQtbBAgrsX+NgMOgkVlo7qUf1Zj3ArIfZej937ifDBc=; b=C1/poJ2EIl3hDLJisOCRga5MZr1+o3BP0hrcHvPyUef4vkAE0+yTxQGJeDZDktciJX Fu2460q3bpN6hAjg9Qhae1knGjrDRzxvX9iJ3u2bE25mPz0SK9K1Msug06jnuySgidEI cz0PBTT3LMIgmZUgsGLZDI15gjm94plO7ED71QzmpmVee1rOR1bm5Z2LuahN5iJKWc1x efK0NUM4mgaZG3vyNI9WCZBs3YTaxfaTO9Df4oKkfTzFJgICLoTvsCbcrAWNLKsjm4VF 8Khn/6VMCURt5vNJirvIM6vfn0QoFFA0W3J9upnKRi3j88ERpw58qMnt0IDc8L/Pqw7o LDNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d36si8793131pla.216.2018.12.09.14.50.02; Sun, 09 Dec 2018 14:50:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726810AbeLIWDR (ORCPT + 99 others); Sun, 9 Dec 2018 17:03:17 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35686 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726604AbeLIVz2 (ORCPT ); Sun, 9 Dec 2018 16:55:28 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72r-0002ih-9t; Sun, 09 Dec 2018 21:55:25 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72k-0003fT-PO; Sun, 09 Dec 2018 21:55:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Linus Torvalds" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 299/328] Make file credentials available to the seqfile interfaces In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 34dbbcdbf63360661ff7bda6c5f52f99ac515f92 upstream. A lot of seqfile users seem to be using things like %pK that uses the credentials of the current process, but that is actually completely wrong for filesystem interfaces. The unix semantics for permission checking files is to check permissions at _open_ time, not at read or write time, and that is not just a small detail: passing off stdin/stdout/stderr to a suid application and making the actual IO happen in privileged context is a classic exploit technique. So if we want to be able to look at permissions at read time, we need to use the file open credentials, not the current ones. Normal file accesses can just use "f_cred" (or any of the helper functions that do that, like file_ns_capable()), but the seqfile interfaces do not have any such options. It turns out that seq_file _does_ save away the user_ns information of the file, though. Since user_ns is just part of the full credential information, replace that special case with saving off the cred pointer instead, and suddenly seq_file has all the permission information it needs. Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings --- fs/seq_file.c | 7 ++++--- include/linux/seq_file.h | 13 ++++--------- 2 files changed, 8 insertions(+), 12 deletions(-) --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -69,9 +69,10 @@ int seq_open(struct file *file, const st memset(p, 0, sizeof(*p)); mutex_init(&p->lock); p->op = op; -#ifdef CONFIG_USER_NS - p->user_ns = file->f_cred->user_ns; -#endif + + // No refcounting: the lifetime of 'p' is constrained + // to the lifetime of the file. + p->file = file; /* * Wrappers around seq_open(e.g. swaps_open) need to be --- a/include/linux/seq_file.h +++ b/include/linux/seq_file.h @@ -7,13 +7,10 @@ #include #include #include +#include +#include struct seq_operations; -struct file; -struct path; -struct inode; -struct dentry; -struct user_namespace; struct seq_file { char *buf; @@ -27,9 +24,7 @@ struct seq_file { struct mutex lock; const struct seq_operations *op; int poll_event; -#ifdef CONFIG_USER_NS - struct user_namespace *user_ns; -#endif + const struct file *file; void *private; }; @@ -151,7 +146,7 @@ int seq_put_decimal_ll(struct seq_file * static inline struct user_namespace *seq_user_ns(struct seq_file *seq) { #ifdef CONFIG_USER_NS - return seq->user_ns; + return seq->file->f_cred->user_ns; #else extern struct user_namespace init_user_ns; return &init_user_ns;