diff options
| author | David S. Miller <davem@davemloft.net> | 2012-05-08 05:35:40 +0200 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2012-05-08 05:35:40 +0200 |
| commit | 0d6c4a2e4641bbc556dd74d3aa158c413a972492 (patch) | |
| tree | da944af17682659bb433dc2282dcb48380c14cd1 /Documentation/security/keys.txt | |
| parent | Merge branch 'vhost-net-next' of git://git.kernel.org/pub/scm/linux/kernel/gi... (diff) | |
| parent | net: compare_ether_addr[_64bits]() has no ordering (diff) | |
| download | linux-0d6c4a2e4641bbc556dd74d3aa158c413a972492.tar.xz linux-0d6c4a2e4641bbc556dd74d3aa158c413a972492.zip | |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Conflicts:
drivers/net/ethernet/intel/e1000e/param.c
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell. In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.
In e1000e a conflict arose in the validation code for settings of
adapter->itr. 'net-next' had more sophisticated logic so that
logic was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/security/keys.txt')
| -rw-r--r-- | Documentation/security/keys.txt | 14 |
1 files changed, 13 insertions, 1 deletions
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index 787717091421..d389acd31e19 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -123,7 +123,7 @@ KEY SERVICE OVERVIEW The key service provides a number of features besides keys: - (*) The key service defines two special key types: + (*) The key service defines three special key types: (+) "keyring" @@ -137,6 +137,18 @@ The key service provides a number of features besides keys: blobs of data. These can be created, updated and read by userspace, and aren't intended for use by kernel services. + (+) "logon" + + Like a "user" key, a "logon" key has a payload that is an arbitrary + blob of data. It is intended as a place to store secrets which are + accessible to the kernel but not to userspace programs. + + The description can be arbitrary, but must be prefixed with a non-zero + length string that describes the key "subclass". The subclass is + separated from the rest of the description by a ':'. "logon" keys can + be created and updated from userspace, but the payload is only + readable from kernel space. + (*) Each process subscribes to three keyrings: a thread-specific keyring, a process-specific keyring, and a session-specific keyring. |