{ "mode": "man", "parameter": "keyrings", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/keyrings/7/json", "generated": "2026-06-13T21:23:37Z", "sections": { "NAME": { "content": "keyrings - in-kernel key management and retention facility\n", "subsections": [] }, "DESCRIPTION": { "content": "The Linux key-management facility is primarily a way for various kernel components to retain\nor cache security data, authentication keys, encryption keys, and other data in the kernel.\n\nSystem call interfaces are provided so that user-space programs can manage those objects and\nalso use the facility for their own purposes; see addkey(2), requestkey(2), and keyctl(2).\n\nA library and some user-space utilities are provided to allow access to the facility. See\nkeyctl(1), keyctl(3), and keyutils(7) for more information.\n", "subsections": [ { "name": "Keys", "content": "A key has the following attributes:\n\nSerial number (ID)\nThis is a unique integer handle by which a key is referred to in system calls. The\nserial number is sometimes synonymously referred as the key ID. Programmatically, key\nserial numbers are represented using the type keyserialt.\n\nType A key's type defines what sort of data can be held in the key, how the proposed con‐\ntent of the key will be parsed, and how the payload will be used.\n\nThere are a number of general-purpose types available, plus some specialist types de‐\nfined by specific kernel components.\n\nDescription (name)\nThe key description is a printable string that is used as the search term for the key\n(in conjunction with the key type) as well as a display name. During searches, the\ndescription may be partially matched or exactly matched.\n\nPayload (data)\nThe payload is the actual content of a key. This is usually set when a key is cre‐\nated, but it is possible for the kernel to upcall to user space to finish the instan‐\ntiation of a key if that key wasn't already known to the kernel when it was requested.\nFor further details, see requestkey(2).\n\nA key's payload can be read and updated if the key type supports it and if suitable\npermission is granted to the caller.\n\nAccess rights\nMuch as files do, each key has an owning user ID, an owning group ID, and a security\nlabel. Each key also has a set of permissions, though there are more than for a nor‐\nmal UNIX file, and there is an additional category—possessor—beyond the usual user,\ngroup, and other (see Possession, below).\n\nNote that keys are quota controlled, since they require unswappable kernel memory.\nThe owning user ID specifies whose quota is to be debited.\n\nExpiration time\nEach key can have an expiration time set. When that time is reached, the key is\nmarked as being expired and accesses to it fail with the error EKEYEXPIRED. If not\ndeleted, updated, or replaced, then, after a set amount of time, an expired key is au‐\ntomatically removed (garbage collected) along with all links to it, and attempts to\naccess the key fail with the error ENOKEY.\n\nReference count\nEach key has a reference count. Keys are referenced by keyrings, by currently active\nusers, and by a process's credentials. When the reference count reaches zero, the key\nis scheduled for garbage collection.\n" }, { "name": "Key types", "content": "The kernel provides several basic types of key:\n\n\"keyring\"\nKeyrings are special keys which store a set of links to other keys (including other\nkeyrings), analogous to a directory holding links to files. The main purpose of a\nkeyring is to prevent other keys from being garbage collected because nothing refers\nto them.\n\nKeyrings with descriptions (names) that begin with a period ('.') are reserved to the\nimplementation.\n\n\"user\" This is a general-purpose key type. The key is kept entirely within kernel memory.\nThe payload may be read and updated by user-space applications.\n\nThe payload for keys of this type is a blob of arbitrary data of up to 32,767 bytes.\n\nThe description may be any valid string, though it is preferred that it start with a\ncolon-delimited prefix representing the service to which the key is of interest (for\ninstance \"afs:mykey\").\n\n\"logon\" (since Linux 3.3)\nThis key type is essentially the same as \"user\", but it does not provide reading\n(i.e., the keyctl(2) KEYCTLREAD operation), meaning that the key payload is never\nvisible from user space. This is suitable for storing username-password pairs that\nshould not be readable from user space.\n\nThe description of a \"logon\" key must start with a non-empty colon-delimited prefix\nwhose purpose is to identify the service to which the key belongs. (Note that this\ndiffers from keys of the \"user\" type, where the inclusion of a prefix is recommended\nbut is not enforced.)\n\n\"bigkey\" (since Linux 3.13)\nThis key type is similar to the \"user\" key type, but it may hold a payload of up to\n1 MiB in size. This key type is useful for purposes such as holding Kerberos ticket\ncaches.\n\nThe payload data may be stored in a tmpfs filesystem, rather than in kernel memory, if\nthe data size exceeds the overhead of storing the data in the filesystem. (Storing\nthe data in a filesystem requires filesystem structures to be allocated in the kernel.\nThe size of these structures determines the size threshold above which the tmpfs stor‐\nage method is used.) Since Linux 4.8, the payload data is encrypted when stored in\ntmpfs, thereby preventing it from being written unencrypted into swap space.\n\nThere are more specialized key types available also, but they aren't discussed here because\nthey aren't intended for normal user-space use.\n\nKey type names that begin with a period ('.') are reserved to the implementation.\n" }, { "name": "Keyrings", "content": "As previously mentioned, keyrings are a special type of key that contain links to other keys\n(which may include other keyrings). Keys may be linked to by multiple keyrings. Keyrings\nmay be considered as analogous to UNIX directories where each directory contains a set of\nhard links to files.\n\nVarious operations (system calls) may be applied only to keyrings:\n\nAdding A key may be added to a keyring by system calls that create keys. This prevents the\nnew key from being immediately deleted when the system call releases its last refer‐\nence to the key.\n\nLinking\nA link may be added to a keyring pointing to a key that is already known, provided\nthis does not create a self-referential cycle.\n\nUnlinking\nA link may be removed from a keyring. When the last link to a key is removed, that\nkey will be scheduled for deletion by the garbage collector.\n\nClearing\nAll the links may be removed from a keyring.\n\nSearching\nA keyring may be considered the root of a tree or subtree in which keyrings form the\nbranches and non-keyrings the leaves. This tree may be searched for a key matching a\nparticular type and description.\n\nSee keyctlclear(3), keyctllink(3), keyctlsearch(3), and keyctlunlink(3) for more informa‐\ntion.\n" }, { "name": "Anchoring keys", "content": "To prevent a key from being garbage collected, it must be anchored to keep its reference\ncount elevated when it is not in active use by the kernel.\n\nKeyrings are used to anchor other keys: each link is a reference on a key. Note that\nkeyrings themselves are just keys and are also subject to the same anchoring requirement to\nprevent them being garbage collected.\n\nThe kernel makes available a number of anchor keyrings. Note that some of these keyrings\nwill be created only when first accessed.\n\nProcess keyrings\nProcess credentials themselves reference keyrings with specific semantics. These\nkeyrings are pinned as long as the set of credentials exists, which is usually as long\nas the process exists.\n\nThere are three keyrings with different inheritance/sharing rules: the ses‐‐\nsion-keyring(7) (inherited and shared by all child processes), the process-keyring(7)\n(shared by all threads in a process) and the thread-keyring(7) (specific to a particu‐\nlar thread).\n\nAs an alternative to using the actual keyring IDs, in calls to addkey(2), keyctl(2),\nand requestkey(2), the special keyring values KEYSPECSESSIONKEYRING,\nKEYSPECPROCESSKEYRING, and KEYSPECTHREADKEYRING can be used to refer to the\ncaller's own instances of these keyrings.\n\nUser keyrings\nEach UID known to the kernel has a record that contains two keyrings: the\nuser-keyring(7) and the user-session-keyring(7). These exist for as long as the UID\nrecord in the kernel exists.\n\nAs an alternative to using the actual keyring IDs, in calls to addkey(2), keyctl(2),\nand requestkey(2), the special keyring values KEYSPECUSERKEYRING and\nKEYSPECUSERSESSIONKEYRING can be used to refer to the caller's own instances of\nthese keyrings.\n\nA link to the user keyring is placed in a new session keyring by pamkeyinit(8) when a\nnew login session is initiated.\n\nPersistent keyrings\nThere is a persistent-keyring(7) available to each UID known to the system. It may\npersist beyond the life of the UID record previously mentioned, but has an expiration\ntime set such that it is automatically cleaned up after a set time. The persistent\nkeyring permits, for example, cron(8) scripts to use credentials that are left in the\npersistent keyring after the user logs out.\n\nNote that the expiration time of the persistent keyring is reset every time the per‐\nsistent key is requested.\n\nSpecial keyrings\nThere are special keyrings owned by the kernel that can anchor keys for special pur‐\nposes. An example of this is the system keyring used for holding encryption keys for\nmodule signature verification.\n\nThese special keyrings are usually closed to direct alteration by user space.\n\nAn originally planned \"group keyring\", for storing keys associated with each GID known to the\nkernel, is not so far implemented, is unlikely to be implemented. Nevertheless, the constant\nKEYSPECGROUPKEYRING has been defined for this keyring.\n" }, { "name": "Possession", "content": "The concept of possession is important to understanding the keyrings security model. Whether\na thread possesses a key is determined by the following rules:\n\n(1) Any key or keyring that does not grant search permission to the caller is ignored in all\nthe following rules.\n\n(2) A thread possesses its session-keyring(7), process-keyring(7), and thread-keyring(7) di‐\nrectly because those keyrings are referred to by its credentials.\n\n(3) If a keyring is possessed, then any key it links to is also possessed.\n\n(4) If any key a keyring links to is itself a keyring, then rule (3) applies recursively.\n\n(5) If a process is upcalled from the kernel to instantiate a key (see requestkey(2)), then\nit also possesses the requester's keyrings as in rule (1) as if it were the requester.\n\nNote that possession is not a fundamental property of a key, but must rather be calculated\neach time the key is needed.\n\nPossession is designed to allow set-user-ID programs run from, say a user's shell to access\nthe user's keys. Granting permissions to the key possessor while denying them to the key\nowner and group allows the prevention of access to keys on the basis of UID and GID matches.\n\nWhen it creates the session keyring, pamkeyinit(8) adds a link to the user-keyring(7), thus\nmaking the user keyring and anything it contains possessed by default.\n" }, { "name": "Access rights", "content": "Each key has the following security-related attributes:\n\n* The owning user ID\n\n* The ID of a group that is permitted to access the key\n\n* A security label\n\n* A permissions mask\n\nThe permissions mask contains four sets of rights. The first three sets are mutually exclu‐\nsive. One and only one will be in force for a particular access check. In order of descend‐\ning priority, these three sets are:\n\nuser The set specifies the rights granted if the key's user ID matches the caller's\nfilesystem user ID.\n\ngroup The set specifies the rights granted if the user ID didn't match and the key's group\nID matches the caller's filesystem GID or one of the caller's supplementary group IDs.\n\nother The set specifies the rights granted if neither the key's user ID nor group ID\nmatched.\n\nThe fourth set of rights is:\n\npossessor\nThe set specifies the rights granted if a key is determined to be possessed by the\ncaller.\n\nThe complete set of rights for a key is the union of whichever of the first three sets is ap‐\nplicable plus the fourth set if the key is possessed.\n\nThe set of rights that may be granted in each of the four masks is as follows:\n\nview The attributes of the key may be read. This includes the type, description, and ac‐\ncess rights (excluding the security label).\n\nread For a key: the payload of the key may be read. For a keyring: the list of serial num‐\nbers (keys) to which the keyring has links may be read.\n\nwrite The payload of the key may be updated and the key may be revoked. For a keyring,\nlinks may be added to or removed from the keyring, and the keyring may be cleared com‐\npletely (all links are removed),\n\nsearch For a key (or a keyring): the key may be found by a search. For a keyring: keys and\nkeyrings that are linked to by the keyring may be searched.\n\nlink Links may be created from keyrings to the key. The initial link to a key that is es‐\ntablished when the key is created doesn't require this permission.\n\nsetattr\nThe ownership details and security label of the key may be changed, the key's expira‐\ntion time may be set, and the key may be revoked.\n\nIn addition to access rights, any active Linux Security Module (LSM) may prevent access to a\nkey if its policy so dictates. A key may be given a security label or other attribute by the\nLSM; this label is retrievable via keyctlgetsecurity(3).\n\nSee keyctlchown(3), keyctldescribe(3), keyctlgetsecurity(3), keyctlsetperm(3), and\nselinux(8) for more information.\n" }, { "name": "Searching for keys", "content": "One of the key features of the Linux key-management facility is the ability to find a key\nthat a process is retaining. The requestkey(2) system call is the primary point of access\nfor user-space applications to find a key. (Internally, the kernel has something similar\navailable for use by internal components that make use of keys.)\n\nThe search algorithm works as follows:\n\n(1) The process keyrings are searched in the following order: the thread thread-keyring(7) if\nit exists, the process-keyring(7) if it exists, and then either the session-keyring(7) if\nit exists or the user-session-keyring(7) if that exists.\n\n(2) If the caller was a process that was invoked by the requestkey(2) upcall mechanism, then\nthe keyrings of the original caller of requestkey(2) will be searched as well.\n\n(3) The search of a keyring tree is in breadth-first order: each keyring is searched first\nfor a match, then the keyrings referred to by that keyring are searched.\n\n(4) If a matching key is found that is valid, then the search terminates and that key is re‐\nturned.\n\n(5) If a matching key is found that has an error state attached, that error state is noted\nand the search continues.\n\n(6) If no valid matching key is found, then the first noted error state is returned; other‐\nwise, an ENOKEY error is returned.\n\nIt is also possible to search a specific keyring, in which case only steps (3) to (6) apply.\n\nSee requestkey(2) and keyctlsearch(3) for more information.\n" }, { "name": "On-demand key creation", "content": "If a key cannot be found, requestkey(2) will, if given a calloutinfo argument, create a new\nkey and then upcall to user space to instantiate the key. This allows keys to be created on\nan as-needed basis.\n\nTypically, this will involve the kernel creating a new process that executes the re‐‐\nquest-key(8) program, which will then execute the appropriate handler based on its configura‐\ntion.\n\nThe handler is passed a special authorization key that allows it and only it to instantiate\nthe new key. This is also used to permit searches performed by the handler program to also\nsearch the requester's keyrings.\n\nSee requestkey(2), keyctlassumeauthority(3), keyctlinstantiate(3), keyctlnegate(3),\nkeyctlreject(3), request-key(8), and request-key.conf(5) for more information.\n" }, { "name": "/proc files", "content": "The kernel provides various /proc files that expose information about keys or define limits\non key usage.\n\n/proc/keys (since Linux 2.6.10)\nThis file exposes a list of the keys for which the reading thread has view permission,\nproviding various information about each key. The thread need not possess the key for\nit to be visible in this file.\n\nThe only keys included in the list are those that grant view permission to the reading\nprocess (regardless of whether or not it possesses them). LSM security checks are\nstill performed, and may filter out further keys that the process is not authorized to\nview.\n\nAn example of the data that one might see in this file (with the columns numbered for\neasy reference below) is the following:\n\n(1) (2) (3)(4) (5) (6) (7) (8) (9)\n009a2028 I--Q--- 1 perm 3f010000 1000 1000 user krbccache:primary: 12\n1806c4ba I--Q--- 1 perm 3f010000 1000 1000 keyring pid: 2\n25d3a08f I--Q--- 1 perm 1f3f0000 1000 65534 keyring uidses.1000: 1\n28576bd8 I--Q--- 3 perm 3f010000 1000 1000 keyring krb: 1\n2c546d21 I--Q--- 190 perm 3f030000 1000 1000 keyring ses: 2\n30a4e0be I------ 4 2d 1f030000 1000 65534 keyring persistent.1000: 1\n32100fab I--Q--- 4 perm 1f3f0000 1000 65534 keyring uid.1000: 2\n32a387ea I--Q--- 1 perm 3f010000 1000 1000 keyring pid: 2\n3ce56aea I--Q--- 5 perm 3f030000 1000 1000 keyring ses: 1\n\nThe fields shown in each line of this file are as follows:\n\nID (1) The ID (serial number) of the key, expressed in hexadecimal.\n\nFlags (2)\nA set of flags describing the state of the key:\n\nI The key has been instantiated.\n\nR The key has been revoked.\n\nD The key is dead (i.e., the key type has been unregistered). (A key may be\nbriefly in this state during garbage collection.)\n\nQ The key contributes to the user's quota.\n\nU The key is under construction via a callback to user space; see re‐‐\nquest-key(2).\n\nN The key is negatively instantiated.\n\ni The key has been invalidated.\n\nUsage (3)\nThis is a count of the number of kernel credential structures that are pinning\nthe key (approximately: the number of threads and open file references that re‐\nfer to this key).\n\nTimeout (4)\nThe amount of time until the key will expire, expressed in human-readable form\n(weeks, days, hours, minutes, and seconds). The string perm here means that\nthe key is permanent (no timeout). The string expd means that the key has al‐\nready expired, but has not yet been garbage collected.\n\nPermissions (5)\nThe key permissions, expressed as four hexadecimal bytes containing, from left\nto right, the possessor, user, group, and other permissions. Within each byte,\nthe permission bits are as follows:\n\n0x01 view\nOx02 read\n0x04 write\n0x08 search\n0x10 link\n0x20 setattr\n\nUID (6)\nThe user ID of the key owner.\n\nGID (7)\nThe group ID of the key. The value -1 here means that the key has no group ID;\nthis can occur in certain circumstances for keys created by the kernel.\n\nType (8)\nThe key type (user, keyring, etc.)\n\nDescription (9)\nThe key description (name). This field contains descriptive information about\nthe key. For most key types, it has the form\n\nname[: extra-info]\n\nThe name subfield is the key's description (name). The optional extra-info\nfield provides some further information about the key. The information that\nappears here depends on the key type, as follows:\n\n\"user\" and \"logon\"\nThe size in bytes of the key payload (expressed in decimal).\n\n\"keyring\"\nThe number of keys linked to the keyring, or the string empty if there\nare no keys linked to the keyring.\n\n\"bigkey\"\nThe payload size in bytes, followed either by the string [file], if the\nkey payload exceeds the threshold that means that the payload is stored\nin a (swappable) tmpfs(5) filesystem, or otherwise the string [buff],\nindicating that the key is small enough to reside in kernel memory.\n\nFor the \".requestkeyauth\" key type (authorization key; see requestkey(2)),\nthe description field has the form shown in the following example:\n\nkey:c9a9b19 pid:28880 ci:10\n\nThe three subfields are as follows:\n\nkey The hexadecimal ID of the key being instantiated in the requesting pro‐\ngram.\n\npid The PID of the requesting program.\n\nci The length of the callout data with which the requested key should be\ninstantiated (i.e., the length of the payload associated with the autho‐\nrization key).\n\n/proc/key-users (since Linux 2.6.10)\nThis file lists various information for each user ID that has at least one key on the\nsystem. An example of the data that one might see in this file is the following:\n\n0: 10 9/9 2/1000000 22/25000000\n42: 9 9/9 8/200 106/20000\n1000: 11 11/11 10/200 271/20000\n\nThe fields shown in each line are as follows:\n\nuid The user ID.\n\nusage This is a kernel-internal usage count for the kernel structure used to record\nkey users.\n\nnkeys/nikeys\nThe total number of keys owned by the user, and the number of those keys that\nhave been instantiated.\n\nqnkeys/maxkeys\nThe number of keys owned by the user, and the maximum number of keys that the\nuser may own.\n\nqnbytes/maxbytes\nThe number of bytes consumed in payloads of the keys owned by this user, and\nthe upper limit on the number of bytes in key payloads for that user.\n\n/proc/sys/kernel/keys/gcdelay (since Linux 2.6.32)\nThe value in this file specifies the interval, in seconds, after which revoked and ex‐\npired keys will be garbage collected. The purpose of having such an interval is so\nthat there is a window of time where user space can see an error (respectively EKEYRE‐‐\nVOKED and EKEYEXPIRED) that indicates what happened to the key.\n\nThe default value in this file is 300 (i.e., 5 minutes).\n\n/proc/sys/kernel/keys/persistentkeyringexpiry (since Linux 3.13)\nThis file defines an interval, in seconds, to which the persistent keyring's expira‐\ntion timer is reset each time the keyring is accessed (via keyctlgetpersistent(3) or\nthe keyctl(2) KEYCTLGETPERSISTENT operation.)\n\nThe default value in this file is 259200 (i.e., 3 days).\n\nThe following files (which are writable by privileged processes) are used to enforce quotas\non the number of keys and number of bytes of data that can be stored in key payloads:\n\n/proc/sys/kernel/keys/maxbytes (since Linux 2.6.26)\nThis is the maximum number of bytes of data that a nonroot user can hold in the pay‐\nloads of the keys owned by the user.\n\nThe default value in this file is 20,000.\n\n/proc/sys/kernel/keys/maxkeys (since Linux 2.6.26)\nThis is the maximum number of keys that a nonroot user may own.\n\nThe default value in this file is 200.\n\n/proc/sys/kernel/keys/rootmaxbytes (since Linux 2.6.26)\nThis is the maximum number of bytes of data that the root user (UID 0 in the root user\nnamespace) can hold in the payloads of the keys owned by root.\n\nThe default value in this file is 25,000,000 (20,000 before Linux 3.17).\n\n/proc/sys/kernel/keys/rootmaxkeys (since Linux 2.6.26)\nThis is the maximum number of keys that the root user (UID 0 in the root user name‐\nspace) may own.\n\nThe default value in this file is 1,000,000 (200 before Linux 3.17).\n\nWith respect to keyrings, note that each link in a keyring consumes 4 bytes of the keyring\npayload.\n" }, { "name": "Users", "content": "The Linux key-management facility has a number of users and usages, but is not limited to\nthose that already exist.\n\nIn-kernel users of this facility include:\n\nNetwork filesystems - DNS\nThe kernel uses the upcall mechanism provided by the keys to upcall to user space to\ndo DNS lookups and then to cache the results.\n\nAFRXRPC and kAFS - Authentication\nThe AFRXRPC network protocol and the in-kernel AFS filesystem use keys to store the\nticket needed to do secured or encrypted traffic. These are then looked up by network\noperations on AFRXRPC and filesystem operations on kAFS.\n\nNFS - User ID mapping\nThe NFS filesystem uses keys to store mappings of foreign user IDs to local user IDs.\n\nCIFS - Password\nThe CIFS filesystem uses keys to store passwords for accessing remote shares.\n\nModule verification\nThe kernel build process can be made to cryptographically sign modules. That signa‐\nture is then checked when a module is loaded.\n\nUser-space users of this facility include:\n\nKerberos key storage\nThe MIT Kerberos 5 facility (libkrb5) can use keys to store authentication tokens\nwhich can be made to be automatically cleaned up a set time after the user last uses\nthem, but until then permits them to hang around after the user has logged out so that\ncron(8) scripts can use them.\n" } ] }, "SEE ALSO": { "content": "keyctl(1), addkey(2), keyctl(2), requestkey(2), keyctl(3), keyutils(7),\npersistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7),\nuser-keyring(7), user-session-keyring(7), pamkeyinit(8), request-key(8)\n\nThe kernel source files Documentation/crypto/asymmetric-keys.txt and under\nDocumentation/security/keys (or, before Linux 4.13, in the file\nDocumentation/security/keys.txt).\n", "subsections": [] }, "COLOPHON": { "content": "This page is part of release 5.10 of the Linux man-pages project. A description of the\nproject, information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux 2020-08-13 KEYRINGS(7)", "subsections": [] } }, "summary": "keyrings - in-kernel key management and retention facility", "flags": [], "examples": [], "see_also": [ { "name": "keyctl", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/keyctl/1/json" }, { "name": "addkey", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/addkey/2/json" }, { "name": "keyctl", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/keyctl/2/json" }, { "name": "requestkey", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/requestkey/2/json" }, { "name": "keyctl", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/keyctl/3/json" }, { "name": "keyutils", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/keyutils/7/json" }, { "name": "persistent-keyring", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/persistent-keyring/7/json" }, { "name": "process-keyring", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/process-keyring/7/json" }, { "name": "session-keyring", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/session-keyring/7/json" }, { "name": "thread-keyring", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/thread-keyring/7/json" }, { "name": "user-keyring", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/user-keyring/7/json" }, { "name": "user-session-keyring", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/user-session-keyring/7/json" }, { "name": "pamkeyinit", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/pamkeyinit/8/json" }, { "name": "request-key", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/request-key/8/json" } ] }