From: David Howells <dhowells@redhat.com>
To: linux-security-module@vger.kernel.org
Subject: Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
Date: Wed, 09 Aug 2017 15:45:47 +0000 [thread overview]
Message-ID: <29920.1502293547@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAK8P3a2STbhgFB5kbVTZqAgY70K_GCaWgj6Kqs4RJOOt2oSd-g@mail.gmail.com>
Arnd Bergmann <arnd@arndb.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
WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: dhowells@redhat.com, Baolin Wang <baolin.wang@linaro.org>,
David Miller <davem@davemloft.net>,
james.l.morris@oracle.com, "Serge E. Hallyn" <serge@hallyn.com>,
marc.dionne@auristor.com,
Dan Carpenter <dan.carpenter@oracle.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Mark Brown <broonie@kernel.org>,
keyrings@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
Date: Wed, 09 Aug 2017 16:45:47 +0100 [thread overview]
Message-ID: <29920.1502293547@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAK8P3a2STbhgFB5kbVTZqAgY70K_GCaWgj6Kqs4RJOOt2oSd-g@mail.gmail.com>
Arnd Bergmann <arnd@arndb.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
WARNING: multiple messages have this Message-ID (diff)
From: dhowells@redhat.com (David Howells)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
Date: Wed, 09 Aug 2017 16:45:47 +0100 [thread overview]
Message-ID: <29920.1502293547@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAK8P3a2STbhgFB5kbVTZqAgY70K_GCaWgj6Kqs4RJOOt2oSd-g@mail.gmail.com>
Arnd Bergmann <arnd@arndb.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
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-08-09 15:45 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-09 2:51 [PATCH 0/3] Fix y2038 issues for security/keys subsystem Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` [PATCH 1/3] security: keys: Replace time_t/timespec with time64_t Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` [PATCH 2/3] security: keys: Replace time_t with time64_t for struct key_preparsed_payload Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 2:51 ` Baolin Wang
2017-08-09 9:01 ` Arnd Bergmann
2017-08-09 9:01 ` Arnd Bergmann
2017-08-09 9:01 ` Arnd Bergmann
2017-08-09 9:33 ` David Howells
2017-08-09 9:33 ` David Howells
2017-08-09 9:33 ` David Howells
2017-08-09 10:00 ` Arnd Bergmann
2017-08-09 10:00 ` Arnd Bergmann
2017-08-09 10:00 ` Arnd Bergmann
2017-08-09 13:26 ` David Howells
2017-08-09 13:26 ` David Howells
2017-08-09 13:26 ` David Howells
2017-08-09 15:12 ` Arnd Bergmann
2017-08-09 15:12 ` Arnd Bergmann
2017-08-09 15:12 ` Arnd Bergmann
2017-08-09 15:45 ` David Howells [this message]
2017-08-09 15:45 ` David Howells
2017-08-09 15:45 ` David Howells
2017-08-09 8:28 ` [PATCH 0/3] Fix y2038 issues for security/keys subsystem David Howells
2017-08-09 8:28 ` David Howells
2017-08-09 8:28 ` David Howells
2017-08-10 1:59 ` Baolin Wang
2017-08-10 1:59 ` Baolin Wang
2017-08-10 1:59 ` Baolin Wang
2017-08-21 12:12 ` Baolin Wang
2017-08-21 12:12 ` Baolin Wang
2017-08-21 12:12 ` Baolin Wang
2017-09-15 8:38 ` Baolin Wang
2017-09-15 8:38 ` Baolin Wang
2017-09-15 8:38 ` Baolin Wang
2017-08-09 8:44 ` Arnd Bergmann
2017-08-09 8:44 ` Arnd Bergmann
2017-08-09 8:44 ` Arnd Bergmann
2017-08-10 2:00 ` Baolin Wang
2017-08-10 2:00 ` Baolin Wang
2017-08-10 2:00 ` Baolin Wang
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=29920.1502293547@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=linux-security-module@vger.kernel.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.