On Mon, Dec 19, 2016 at 8:47 AM, Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: > On 12/19/2016 09:19 AM, David Howells wrote: >> Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: >> >>> Otherwise, if dest_keyring is 0 and a new key is constructed, the new >>> key will be linked to the "default" keyring. More precisely, when the >>> kernel tries to determine to which keyring the newly constructed key >>> should be linked, it tries the following keyrings, beginning with the >>> keyring set via the keyctl(2) KEYCTL_SET_REQKEY_KEYRING command and >>> continuing in the order shown below until it finds the first keyring >>> that exists: >>> >>> · The requestor keyring (KEY_REQKEY_DEFL_REQUESTOR_KEYRING, since >>> Linux 2.6.29). >> >> This is only available in the /sbin/request-key upcall, where it refers back >> to the destination keyring of whoever called request_key(). > > Eugene has sent a longer analysis, which I didn't yet scan thoroughly. > But, I feel like I must be missing something obvious. (And unfortunately, my > FIXME text was a bit garbled). Here, we're talking about the situation where > request_key(2) is called with a destination keyring argument (final argument > to the call) that is 0. Does not KEY_REQKEY_DEFL_REQUESTOR_KEYRING then yield > "0" as its value, and thus this case is a no-op in the list of keyrings searched?. > (Is there something here that I'm missing to do with chained upcalls?) After the successful keyctl(KEYCTL_ASSUME_AUTHORITY, dest_key_id) call (where dest_key_id is the key_id passed to the upcalled program in the second parameter), the request_key_auth field of the cred structure would be set with the appropriate authkey, which enables entering into the condition at request_key.c:271. Otherwise this condition would be passed. >>> · The session keyring for the process's user ID >>> (KEY_REQKEY_DEFL_USER_SESSION_KEYRING). This keyring is expected to >>> always exist. >>> >>> ┌─────────────────────────────────────────────────────┐ >>> │FIXME │ >>> ├─────────────────────────────────────────────────────┤ >>> │Are there circumstances where the session keyring │ >>> │does not exist? What are they? │ >>> └─────────────────────────────────────────────────────┘ >> >> The session keyring does not exist in /sbin/init's process, for example, >> unless that process created one. It's existence or non-existence is then >> inherited by all the processes that are started from that. Upon a log-in, PAM >> is expected to create a session keyring. >> >>> · The UID-specific keyring (KEY_REQKEY_DEFL_USER_KEYRING). This >>> keyring is also expected to always exist. >>> >>> ┌─────────────────────────────────────────────────────┐ >>> │FIXME │ >>> ├─────────────────────────────────────────────────────┤ >>> │Are there circumstances where the UID-specific │ >>> │keyring does not exist? What are they? │ >>> └─────────────────────────────────────────────────────┘ >> >> The uid keyrings don't exist until someone tries to access them - at which >> point they're both created. > > Does "access" here mean attempt to "read ow update" the keyring, or are the > UID keyring created only on the first attempt to "update: them? > > Cheers, > > Michael > >> When you log in, pam_keyinit creates a link to >> your user keyring in the session keyring it just created, thereby creating the >> user and user-session keyrings. >> >> David >> > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ -- Eugene Syromyatnikov mailto:evgsyr@xxxxxxxxx xmpp:esyr@jabber.{ru|org} ��.n��������+%������w��{.n�����{��f��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
