Re: [PATCH 1/5] request_key.2: add information regarding default keyring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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().

>        ·  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.  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
��.n��������+%������w��{.n�����{��f��)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux