[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29920.1502293547@warthog.procyon.org.uk>
Date: Wed, 09 Aug 2017 16:45:47 +0100
From: David Howells <dhowells@...hat.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: dhowells@...hat.com, Baolin Wang <baolin.wang@...aro.org>,
David Miller <davem@...emloft.net>, james.l.morris@...cle.com,
"Serge E. Hallyn" <serge@...lyn.com>, marc.dionne@...istor.com,
Dan Carpenter <dan.carpenter@...cle.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Mark Brown <broonie@...nel.org>, keyrings@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
Arnd Bergmann <arnd@...db.de> wrote:
> Ah, I'm slowly starting to understand how this fits together. So you can add
> a key either through key_add() from local user space, or through an rxrpc
> socket.
No, you can't add keys through an rxrpc socket.
There are three 'classes' of key:
(1) Client keys (type rxrpc). These must be added by add_key() by userspace
(but could also be acquired by upcalling to /sbin/request-key) and then
the kernel calls request_key() to locate them on entry through either a
kafs inode/file operation or through sendmsg() to an AF_RXRPC socket.
(2) Server keys (type rxrpc_s). These are created by userspace and are
presented to an AF_RXRPC server socket by calling setsockopt(). The
server uses these to validate/decrypt the token passed by a RESPONSE
packet.
(3) Service connection keys (type rxrpc). These are created internally by
AF_RXRPC after a successful challenge/response negotiation to hold the
security details so that we have a struct key to pass around that
corresponds to the key in (1).
David
Powered by blists - more mailing lists