Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932803AbbHXJwO (ORCPT ); Mon, 24 Aug 2015 05:52:14 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:35235 "EHLO mail-lb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932427AbbHXJwM (ORCPT ); Mon, 24 Aug 2015 05:52:12 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 24 Aug 2015 11:52:10 +0200 Message-ID: Subject: Re: kdbus_proc_permission (Re: [GIT PULL] kdbus updates for Greg) From: David Herrmann To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , Greg KH Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1800 Lines: 44 Hi On Mon, Aug 10, 2015 at 4:42 AM, Andy Lutomirski wrote: > I spotted this: > > +/** > + * kdbus_proc_permission() - check /proc permissions on target pid > + * @pid_ns: namespace we operate in > + * @cred: credentials of requestor > + * @target: target process > + * > + * This checks whether a process with credentials @cred can access information > + * of @target in the namespace @pid_ns. This tries to follow /proc permissions, > + * but is slightly more restrictive. > + * > + * Return: The /proc access level (KDBUS_META_PROC_*) is returned. > + */ > +static unsigned int kdbus_proc_permission(const struct pid_namespace *pid_ns, > + const struct cred *cred, > + struct pid *target) > > That code ended up in a pull request, although AFAICT it was never in > any patch email sent to me or to any public mailing list. I suspect > it was at least partially a response to one of my old reviews. Exactly. It's an attempt to model metadata access similar to /proc access (thus, access to kdbusfs implies access to procfs, but not vice versa (nor any implication on hidepid)). > I haven't checked the context in which it's used, but in order for > kdbus_proc_permission to do what it claims to do, it appears to be > missing calls to security_inode_permission and > security_file_permission. Both are expected to be added by lsm patches (both hooks you mentioned are empty if no lsm is selected). Thanks David -- 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/