From: ebiederm@xmission.com (Eric W. Biederman)
To: Matthew Wilcox <willy@infradead.org>
Cc: Stephen Brennan <stephen.s.brennan@oracle.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-security-module@vger.kernel.org,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>,
Eric Paris <eparis@parisplace.org>,
selinux@vger.kernel.org, Casey Schaufler <casey@schaufler-ca.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] proc: Allow pid_revalidate() during LOOKUP_RCU
Date: Sun, 13 Dec 2020 08:22:32 -0600 [thread overview]
Message-ID: <877dpln5uf.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20201212205522.GF2443@casper.infradead.org> (Matthew Wilcox's message of "Sat, 12 Dec 2020 20:55:22 +0000")
Matthew Wilcox <willy@infradead.org> writes:
> On Thu, Dec 03, 2020 at 04:02:12PM -0800, Stephen Brennan wrote:
>> -void pid_update_inode(struct task_struct *task, struct inode *inode)
>> +static int do_pid_update_inode(struct task_struct *task, struct inode *inode,
>> + unsigned int flags)
>
> I'm really nitpicking here, but this function only _updates_ the inode
> if flags says it should. So I was thinking something like this
> (compile tested only).
>
> I'd really appreocate feedback from someone like Casey or Stephen on
> what they need for their security modules.
Just so we don't have security module questions confusing things
can we please make this a 2 patch series? With the first
patch removing security_task_to_inode?
The justification for the removal is that all security_task_to_inode
appears to care about is the file type bits in inode->i_mode. Something
that never changes. Having this in a separate patch would make that
logical change easier to verify.
Eric
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index b362523a9829..771f330bfce7 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1968,6 +1968,25 @@ void pid_update_inode(struct task_struct *task, struct inode *inode)
> security_task_to_inode(task, inode);
> }
>
> +/* See if we can avoid the above call. Assumes RCU lock held */
> +static bool inode_needs_pid_update(struct task_struct *task,
> + const struct inode *inode)
> +{
> + kuid_t uid;
> + kgid_t gid;
> +
> + if (inode->i_mode & (S_ISUID | S_ISGID))
> + return true;
> + task_dump_owner(task, inode->i_mode, &uid, &gid);
> + if (!uid_eq(uid, inode->i_uid) || !gid_eq(gid, inode->i_gid))
> + return true;
> + /*
> + * XXX: Do we need to call the security system here to see if
> + * there's a pending update?
> + */
> + return false;
> +}
> +
> /*
> * Rewrite the inode's ownerships here because the owning task may have
> * performed a setuid(), etc.
> @@ -1978,8 +1997,15 @@ static int pid_revalidate(struct dentry *dentry, unsigned int flags)
> struct inode *inode;
> struct task_struct *task;
>
> - if (flags & LOOKUP_RCU)
> + if (flags & LOOKUP_RCU) {
> + inode = d_inode_rcu(dentry);
> + task = pid_task(proc_pid(inode), PIDTYPE_PID);
> + if (!task)
> + return 0;
> + if (!inode_needs_pid_update(task, inode))
> + return 1;
> return -ECHILD;
> + }
>
> inode = d_inode(dentry);
> task = get_proc_task(inode);
next prev parent reply other threads:[~2020-12-13 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 0:02 [PATCH v2] proc: Allow pid_revalidate() during LOOKUP_RCU Stephen Brennan
2020-12-12 20:55 ` Matthew Wilcox
2020-12-13 14:22 ` Eric W. Biederman [this message]
2020-12-13 16:29 ` Matthew Wilcox
2020-12-13 23:00 ` Paul Moore
2020-12-15 18:09 ` Casey Schaufler
2020-12-15 22:04 ` Eric W. Biederman
2020-12-15 22:53 ` Casey Schaufler
2020-12-16 1:05 ` Stephen Brennan
2020-12-14 18:45 ` Casey Schaufler
2020-12-14 18:15 ` Stephen Brennan
2020-12-13 14:30 ` Eric W. Biederman
2020-12-13 16:32 ` Matthew Wilcox
2020-12-14 17:19 ` Stephen Brennan
2020-12-15 21:45 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877dpln5uf.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=casey@schaufler-ca.com \
--cc=eparis@parisplace.org \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=stephen.s.brennan@oracle.com \
--cc=stephen.smalley.work@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.