[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <14149.1567105917@warthog.procyon.org.uk>
Date: Thu, 29 Aug 2019 20:11:57 +0100
From: David Howells <dhowells@...hat.com>
To: Stephen Smalley <sds@...ho.nsa.gov>
Cc: dhowells@...hat.com, viro@...iv.linux.org.uk,
Casey Schaufler <casey@...aufler-ca.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
nicolas.dichtel@...nd.com, raven@...maw.net,
Christian Brauner <christian@...uner.io>,
keyrings@...r.kernel.org, linux-usb@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/11] selinux: Implement the watch_key security hook [ver #6]
Stephen Smalley <sds@...ho.nsa.gov> wrote:
> Can watch->cred ever differ from current's cred here? If not, why can't we
> just use current_sid() here
Um. Not currently. I'm not sure whether its ever likely to be otherwise.
Probably we could just use that and fix it up later if we do find otherwise.
> and why do we need the watch object at all?
It carries more than just the creds for the caller of keyctl_watch_key(), it
also carries information about the queue to which notifications will be
written, including the creds that were active when that was set up.
Note that there's no requirement that the process that opened /dev/watch_queue
be the one that sets the watch. In the keyutils testsuite, I 'leak' a file
descriptor from the session wrangler into the program that it runs so that
tests running inside the test script can add watches to it.
David
Powered by blists - more mailing lists