From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Eugene Syromyatnikov <evgsyr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/5] request_key.2: add information regarding default keyring
Date: Fri, 25 Nov 2016 11:01:17 +0100 [thread overview]
Message-ID: <54aa766c-25de-74ba-fba5-59cd95b2ae91@gmail.com> (raw)
In-Reply-To: <20161121205940.GA16505@obsidian>
Hi Eugene,
On 11/21/2016 09:59 PM, Eugene Syromyatnikov wrote:
> ---
> man2/request_key.2 | 47 ++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 42 insertions(+), 5 deletions(-)
>
> diff --git a/man2/request_key.2 b/man2/request_key.2
> index a9d0561..e29ca06 100644
> --- a/man2/request_key.2
> +++ b/man2/request_key.2
> @@ -35,11 +35,6 @@ If the key is found or created,
> attaches it to the keyring whose ID is specified in
> .I dest_keyring
> and returns the key's serial number.
> -.\" FIXME Is 'keyring' allowed to be 0? Reading the source, it appears so.
> -.\" In this case, by default, the key is assigned to the session keyring.
> -.\" But, the KEYCTL_SET_REQKEY_KEYRING also seems to have an influence here.
> -.\" What are the details here?
> -.\"
>
> .BR request_key ()
> first recursively searches for a matching key in all of the keyrings
> @@ -104,6 +99,48 @@ This specifies the caller's UID-specific keyring
> .B KEY_SPEC_USER_SESSION_KEYRING
> This specifies the caller's UID-session keyring
> .RB ( user-session-keyring (7)).
> +.PP
> +When the
> +.I dest_keyring
> +is specified to
> +.BR 0 ,
> +and no key construction have been performed, then no additional linking is done.
> +Otherwise, if new key is constructed, it would be linked to the "default"
> +keyring (which can be specified via the
> +.BR keyctl (2)
> +command
> +.BR KEYCTL_SET_REQKEY_KEYRING ).
For the purpose of me reviewing this, could you outline how you verified
the following details:
> +More specifically, when kernel tries to determine to which keyring the
> +newly constructed key should be linked, it tries the following options, starting
> +from the value set via
> +.BR KEYCTL_SET_REQKEY_KEYRING " " keyctl (2)
> +command until it finds the first available one:
> +.IP \(bu 3
> +.\" 8bbf4976b59fc9fc2861e79cab7beb3f6d647640
> +Requestor keyring (specified via
> +.BR KEY_REQKEY_DEFL_REQUESTOR_KEYRING ,
> +since Linux 2.6.29)
> +.IP \(bu
> +Thread-specific keyring (specified via
> +.BR KEY_REQKEY_DEFL_THREAD_KEYRING )
> +.IP \(bu
> +Process-specific keyring (specified via
> +.BR KEY_REQKEY_DEFL_PROCESS_KEYRING )
> +.IP \(bu
> +Session-specific keyring (specified via
> +.BR KEY_REQKEY_DEFL_SESSION_KEYRING )
> +.IP \(bu
> +Session keyring for the process's user ID (specified via
> +.BR KEY_REQKEY_DEFL_USER_SESSION_KEYRING ).
> +This keyring is expected to always exist.
> +.IP \(bu
> +UID-specific keyring (specified via
> +.BR KEY_REQKEY_DEFL_USER_KEYRING ).
> +This keyring is also expected to always exist.
> +.PP
> +Specifying
> +.B KEY_REQKEY_DEFL_DEFAULT
> +leads to starting from the beginning of the list.
> .\"
> .SS Requesting user-space instantiation of a key
> If the kernel cannot find a key matching
>
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-11-25 10:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 15:45 Revised request_key(2) man page for review Michael Kerrisk (man-pages)
[not found] ` <528b203d-ac72-e4a6-8517-e8c5c11055a4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-21 20:59 ` [PATCH 0/5] " Eugene Syromyatnikov
2016-11-21 22:33 ` Michael Kerrisk (man-pages)
2016-11-21 20:59 ` [PATCH 1/5] request_key.2: add information regarding default keyring Eugene Syromyatnikov
2016-11-21 22:08 ` Michael Kerrisk (man-pages)
2016-11-25 10:01 ` Michael Kerrisk (man-pages) [this message]
[not found] ` <54aa766c-25de-74ba-fba5-59cd95b2ae91-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 20:11 ` Eugene Syromyatnikov
2016-12-13 13:20 ` Michael Kerrisk (man-pages)
2016-12-17 12:21 ` Michael Kerrisk (man-pages)
[not found] ` <6df2c812-c2d6-321c-902f-93b4d3aaa953-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-12-18 6:40 ` Eugene Syromyatnikov
2016-12-19 8:19 ` David Howells
[not found] ` <15546.1482135577-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2016-12-19 8:47 ` Michael Kerrisk (man-pages)
[not found] ` <f06829ea-1d7c-3f9a-1f4b-e6880aacbdc2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-12-19 9:31 ` Eugene Syromyatnikov
2016-12-20 9:14 ` David Howells
2016-11-21 20:59 ` [PATCH 2/5] requesT_key.2: add information regarding minimal kernel version for key instantiation on request Eugene Syromyatnikov
2016-11-21 22:00 ` Michael Kerrisk (man-pages)
2016-11-21 20:59 ` [PATCH 3/5] request_key.2: whitespace fix Eugene Syromyatnikov
2016-11-21 21:59 ` Michael Kerrisk (man-pages)
2016-11-21 21:00 ` [PATCH 4/5] request_key.2: wfix Eugene Syromyatnikov
2016-11-21 21:59 ` Michael Kerrisk (man-pages)
2016-11-21 21:00 ` [PATCH 5/5] request_key.2: additional error information Eugene Syromyatnikov
2016-11-21 22:00 ` Michael Kerrisk (man-pages)
2016-12-14 14:23 ` Revised request_key(2) man page for review Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkiOzLwoLN-Kaa3-jHUJuYxp-YcL-5FbCe-pOkxGq_u5-g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-15 10:10 ` David Howells
[not found] ` <23323.1481796656-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2016-12-17 10:34 ` Michael Kerrisk (man-pages)
[not found] ` <00a561ef-34c2-40e0-335d-66d34518ba8d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-12-19 8:13 ` David Howells
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=54aa766c-25de-74ba-fba5-59cd95b2ae91@gmail.com \
--to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=evgsyr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).