09 Jan, 2012
1 commit
-
Conflicts:
security/integrity/evm/evm_crypto.cResolved upstream fix vs. next conflict manually.
Signed-off-by: James Morris
17 Nov, 2011
3 commits
-
Give keys their own lockdep class to differentiate them from each other in case
a key of one type has to refer to a key of another type.Signed-off-by: David Howells
Acked-by: Mimi Zohar
Signed-off-by: James Morris -
Encrypted keys are encrypted/decrypted using either a trusted or
user-defined key type, which is referred to as the 'master' key.
The master key may be of type trusted iff the trusted key is
builtin or both the trusted key and encrypted keys are built as
modules. This patch resolves the build dependency problem.- Use "masterkey-$(CONFIG_TRUSTED_KEYS)-$(CONFIG_ENCRYPTED_KEYS)" construct
to encapsulate the above logic. (Suggested by Dimtry Kasatkin.)
- Fixing the encrypted-keys Makefile, results in a module name change
from encrypted.ko to encrypted-keys.ko.
- Add module dependency for request_trusted_key() definitionSigned-off-by: Mimi Zohar
-
Fix request_master_key() error return code.
Signed-off-by: Mimi Zohar
16 Nov, 2011
1 commit
-
Fix a NULL pointer deref in the user-defined key type whereby updating a
negative key into a fully instantiated key will cause an oops to occur
when the code attempts to free the non-existent old payload.This results in an oops that looks something like the following:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [] __call_rcu+0x11/0x13e
PGD 3391d067 PUD 3894a067 PMD 0
Oops: 0002 [#1] SMP
CPU 1
Pid: 4354, comm: keyctl Not tainted 3.1.0-fsdevel+ #1140 /DG965RY
RIP: 0010:[] [] __call_rcu+0x11/0x13e
RSP: 0018:ffff88003d591df8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000006e
RDX: ffffffff8161d0c0 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88003d591e18 R08: 0000000000000000 R09: ffffffff8152fa6c
R10: 0000000000000000 R11: 0000000000000300 R12: ffff88003b8f9538
R13: ffffffff8161d0c0 R14: ffff88003b8f9d50 R15: ffff88003c69f908
FS: 00007f97eb18c720(0000) GS:ffff88003bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000003d47a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process keyctl (pid: 4354, threadinfo ffff88003d590000, task ffff88003c78a040)
Stack:
ffff88003e0ffde0 ffff88003b8f9538 0000000000000001 ffff88003b8f9d50
ffff88003d591e28 ffffffff810860f0 ffff88003d591e68 ffffffff8117bfea
ffff88003d591e68 ffffffff00000000 ffff88003e0ffde1 ffff88003e0ffde0
Call Trace:
[] call_rcu_sched+0x10/0x12
[] user_update+0x8d/0xa2
[] key_create_or_update+0x236/0x270
[] sys_add_key+0x123/0x17e
[] system_call_fastpath+0x16/0x1bSigned-off-by: David Howells
Acked-by: Jeff Layton
Acked-by: Neil Horman
Acked-by: Steve Dickson
Acked-by: James Morris
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
01 Nov, 2011
2 commits
-
There is no functional change.
Signed-off-by: Andy Shevchenko
Cc: Mimi Zohar
Cc: James Morris
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The basic idea behind cross memory attach is to allow MPI programs doing
intra-node communication to do a single copy of the message rather than a
double copy of the message via shared memory.The following patch attempts to achieve this by allowing a destination
process, given an address and size from a source process, to copy memory
directly from the source process into its own address space via a system
call. There is also a symmetrical ability to copy from the current
process's address space into a destination process's address space.- Use of /proc/pid/mem has been considered, but there are issues with
using it:
- Does not allow for specifying iovecs for both src and dest, assuming
preadv or pwritev was implemented either the area read from or
written to would need to be contiguous.
- Currently mem_read allows only processes who are currently
ptrace'ing the target and are still able to ptrace the target to read
from the target. This check could possibly be moved to the open call,
but its not clear exactly what race this restriction is stopping
(reason appears to have been lost)
- Having to send the fd of /proc/self/mem via SCM_RIGHTS on unix
domain socket is a bit ugly from a userspace point of view,
especially when you may have hundreds if not (eventually) thousands
of processes that all need to do this with each other
- Doesn't allow for some future use of the interface we would like to
consider adding in the future (see below)
- Interestingly reading from /proc/pid/mem currently actually
involves two copies! (But this could be fixed pretty easily)As mentioned previously use of vmsplice instead was considered, but has
problems. Since you need the reader and writer working co-operatively if
the pipe is not drained then you block. Which requires some wrapping to
do non blocking on the send side or polling on the receive. In all to all
communication it requires ordering otherwise you can deadlock. And in the
example of many MPI tasks writing to one MPI task vmsplice serialises the
copying.There are some cases of MPI collectives where even a single copy interface
does not get us the performance gain we could. For example in an
MPI_Reduce rather than copy the data from the source we would like to
instead use it directly in a mathops (say the reduce is doing a sum) as
this would save us doing a copy. We don't need to keep a copy of the data
from the source. I haven't implemented this, but I think this interface
could in the future do all this through the use of the flags - eg could
specify the math operation and type and the kernel rather than just
copying the data would apply the specified operation between the source
and destination and store it in the destination.Although we don't have a "second user" of the interface (though I've had
some nibbles from people who may be interested in using it for intra
process messaging which is not MPI). This interface is something which
hardware vendors are already doing for their custom drivers to implement
fast local communication. And so in addition to this being useful for
OpenMPI it would mean the driver maintainers don't have to fix things up
when the mm changes.There was some discussion about how much faster a true zero copy would
go. Here's a link back to the email with some testing I did on that:http://marc.info/?l=linux-mm&m=130105930902915&w=2
There is a basic man page for the proposed interface here:
http://ozlabs.org/~cyeoh/cma/process_vm_readv.txt
This has been implemented for x86 and powerpc, other architecture should
mainly (I think) just need to add syscall numbers for the process_vm_readv
and process_vm_writev. There are 32 bit compatibility versions for
64-bit kernels.For arch maintainers there are some simple tests to be able to quickly
verify that the syscalls are working correctly here:http://ozlabs.org/~cyeoh/cma/cma-test-20110718.tgz
Signed-off-by: Chris Yeoh
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Arnd Bergmann
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: David Howells
Cc: James Morris
Cc:
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
21 Sep, 2011
2 commits
-
For each hex2bin call in encrypted keys, check that the ascii hex string
is valid. On failure, return -EINVAL.Changelog v1:
- hex2bin now returns an intSigned-off-by: Mimi Zohar
Acked-by: Andy Shevchenko -
For each hex2bin call in trusted keys, check that the ascii hex string is
valid. On failure, return -EINVAL.Changelog v1:
- hex2bin now returns an intSigned-off-by: Mimi Zohar
Acked-by: Andy Shevchenko
16 Sep, 2011
1 commit
-
Fixes this build error:
security/keys/encrypted-keys/masterkey_trusted.c: In function 'request_trusted_key':
security/keys/encrypted-keys/masterkey_trusted.c:35:2: error: implicit declaration of function 'IS_ERR'Signed-off-by: Stephen Rothwell
Signed-off-by: Mimi Zohar
15 Sep, 2011
2 commits
-
Encrypted keys are decrypted/encrypted using either a trusted-key or,
for those systems without a TPM, a user-defined key. This patch
removes the trusted-keys and TCG_TPM dependencies.Signed-off-by: Mimi Zohar
-
Move all files associated with encrypted keys to keys/encrypted-keys.
Signed-off-by: Mimi Zohar
23 Aug, 2011
7 commits
-
unregister_key_type() has code to mark a key as dead and make it unavailable in
one loop and then destroy all those unavailable key payloads in the next loop.
However, the loop to mark keys dead renders the key undetectable to the second
loop by changing the key type pointer also.Fix this by the following means:
(1) The key code has two garbage collectors: one deletes unreferenced keys and
the other alters keyrings to delete links to old dead, revoked and expired
keys. They can end up holding each other up as both want to scan the key
serial tree under spinlock. Combine these into a single routine.(2) Move the dead key marking, dead link removal and dead key removal into the
garbage collector as a three phase process running over the three cycles
of the normal garbage collection procedure. This is tracked by the
KEY_GC_REAPING_DEAD_1, _2 and _3 state flags.unregister_key_type() then just unlinks the key type from the list, wakes
up the garbage collector and waits for the third phase to complete.(3) Downgrade the key types sem in unregister_key_type() once it has deleted
the key type from the list so that it doesn't block the keyctl() syscall.(4) Dead keys that cannot be simply removed in the third phase have their
payloads destroyed with the key's semaphore write-locked to prevent
interference by the keyctl() syscall. There should be no in-kernel users
of dead keys of that type by the point of unregistration, though keyctl()
may be holding a reference.(5) Only perform timer recalculation in the GC if the timer actually expired.
If it didn't, we'll get another cycle when it goes off - and if the key
that actually triggered it has been removed, it's not a problem.(6) Only garbage collect link if the timer expired or if we're doing dead key
clean up phase 2.(7) As only key_garbage_collector() is permitted to use rb_erase() on the key
serial tree, it doesn't need to revalidate its cursor after dropping the
spinlock as the node the cursor points to must still exist in the tree.(8) Drop the spinlock in the GC if there is contention on it or if we need to
reschedule. After dealing with that, get the spinlock again and resume
scanning.This has been tested in the following ways:
(1) Run the keyutils testsuite against it.
(2) Using the AF_RXRPC and RxKAD modules to test keytype removal:
Load the rxrpc_s key type:
# insmod /tmp/af-rxrpc.ko
# insmod /tmp/rxkad.koCreate a key (http://people.redhat.com/~dhowells/rxrpc/listen.c):
# /tmp/listen &
[1] 8173Find the key:
# grep rxrpc_s /proc/keys
091086e1 I--Q-- 1 perm 39390000 0 0 rxrpc_s 52:2Link it to a session keyring, preferably one with a higher serial number:
# keyctl link 0x20e36251 @s
Kill the process (the key should remain as it's linked to another place):
# fg
/tmp/listen
^CRemove the key type:
rmmod rxkad
rmmod af-rxrpcThis can be made a more effective test by altering the following part of
the patch:if (unlikely(gc_state & KEY_GC_REAPING_DEAD_2)) {
/* Make sure everyone revalidates their keys if we marked a
* bunch as being dead and make sure all keyring ex-payloads
* are destroyed.
*/
kdebug("dead sync");
synchronize_rcu();To call synchronize_rcu() in GC phase 1 instead. That causes that the
keyring's old payload content to hang around longer until it's RCU
destroyed - which usually happens after GC phase 3 is complete. This
allows the destroy_dead_key branch to be tested.Reported-by: Benjamin Coddington
Signed-off-by: David Howells
Signed-off-by: James Morris -
The dead key link reaper should be non-reentrant as it relies on global state
to keep track of where it's got to when it returns to the work queue manager to
give it some air.Signed-off-by: David Howells
Signed-off-by: James Morris -
Make the key reaper non-reentrant by sticking it on the appropriate system work
queue when we queue it. This will allow it to have global state and drop
locks. It should probably be non-reentrant already as it may spend a long time
holding the key serial spinlock, and so multiple entrants can spend long
periods of time just sitting there spinning, waiting to get the lock.Signed-off-by: David Howells
Signed-off-by: James Morris -
Move the unreferenced key reaper function to the keys garbage collector file
as that's a more appropriate place with the dead key link reaper.Signed-off-by: David Howells
Signed-off-by: James Morris -
__key_link() should use the RCU deref wrapper rcu_dereference_locked_keyring()
for accessing keyring payloads rather than calling rcu_dereference_protected()
directly.Signed-off-by: David Howells
Signed-off-by: James Morris -
The keyctl call:
keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1)
should create a session keyring if the process doesn't have one of its own
because the create flag argument is set - rather than subscribing to and
returning the user-session keyring as:keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0)
will do.
This can be tested by commenting out pam_keyinit in the /etc/pam.d files and
running the following program a couple of times in a row:#include
#include
#include
int main(int argc, char *argv[])
{
key_serial_t uk, usk, sk, nsk;
uk = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);
usk = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);
sk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0);
nsk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 1);
printf("keys: %08x %08x %08x %08x\n", uk, usk, sk, nsk);
return 0;
}Without this patch, I see:
keys: 3975ddc7 119c0c66 119c0c66 119c0c66
keys: 3975ddc7 119c0c66 119c0c66 119c0c66With this patch, I see:
keys: 2cb4997b 34112878 34112878 17db2ce3
keys: 2cb4997b 34112878 34112878 39f3c73eAs can be seen, the session keyring starts off the same as the user-session
keyring each time, but with the patch a new session keyring is created when
the create flag is set.Reported-by: Greg Wettstein
Signed-off-by: David Howells
Tested-by: Greg Wettstein
Signed-off-by: James Morris -
If install_session_keyring() is given a keyring, it should install it rather
than just creating a new one anyway. This was accidentally broken in:commit d84f4f992cbd76e8f39c488cf0c5d123843923b1
Author: David Howells
Date: Fri Nov 14 10:39:23 2008 +1100
Subject: CRED: Inaugurate COW credentialsThe impact of that commit is that pam_keyinit no longer works correctly if
'force' isn't specified against a login process. This is because:keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0)
now always creates a new session keyring and thus the check whether the session
keyring and the user-session keyring are the same is always false. This leads
pam_keyinit to conclude that a session keyring is installed and it shouldn't be
revoked by pam_keyinit here if 'revoke' is specified.Any system that specifies 'force' against pam_keyinit in the PAM configuration
files for login methods (login, ssh, su -l, kdm, etc.) is not affected since
that bypasses the broken check and forces the creation of a new session keyring
anyway (for which the revoke flag is not cleared) - and any subsequent call to
pam_keyinit really does have a session keyring already installed, and so the
check works correctly there.Reverting to the previous behaviour will cause the kernel to subscribe the
process to the user-session keyring as its session keyring if it doesn't have a
session keyring of its own. pam_keyinit will detect this and install a new
session keyring anyway (and won't clear the revert flag).This can be tested by commenting out pam_keyinit in the /etc/pam.d files and
running the following program a couple of times in a row:#include
#include
#include
int main(int argc, char *argv[])
{
key_serial_t uk, usk, sk;
uk = keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);
usk = keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);
sk = keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0);
printf("keys: %08x %08x %08x\n", uk, usk, sk);
return 0;
}Without the patch, I see:
keys: 3884e281 24c4dfcf 22825f8e
keys: 3884e281 24c4dfcf 068772beWith the patch, I see:
keys: 26be9c83 0e755ce0 0e755ce0
keys: 26be9c83 0e755ce0 0e755ce0As can be seen, with the patch, the session keyring is the same as the
user-session keyring each time; without the patch a new session keyring is
generated each time.Reported-by: Greg Wettstein
Signed-off-by: David Howells
Tested-by: Greg Wettstein
Signed-off-by: James Morris
28 Jul, 2011
1 commit
-
…s/security-testing-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: (54 commits)
tpm_nsc: Fix bug when loading multiple TPM drivers
tpm: Move tpm_tis_reenable_interrupts out of CONFIG_PNP block
tpm: Fix compilation warning when CONFIG_PNP is not defined
TOMOYO: Update kernel-doc.
tpm: Fix a typo
tpm_tis: Probing function for Intel iTPM bug
tpm_tis: Fix the probing for interrupts
tpm_tis: Delay ACPI S3 suspend while the TPM is busy
tpm_tis: Re-enable interrupts upon (S3) resume
tpm: Fix display of data in pubek sysfs entry
tpm_tis: Add timeouts sysfs entry
tpm: Adjust interface timeouts if they are too small
tpm: Use interface timeouts returned from the TPM
tpm_tis: Introduce durations sysfs entry
tpm: Adjust the durations if they are too small
tpm: Use durations returned from TPM
TOMOYO: Enable conditional ACL.
TOMOYO: Allow using argv[]/envp[] of execve() as conditions.
TOMOYO: Allow using executable's realpath and symlink's target as conditions.
TOMOYO: Allow using owner/group etc. of file objects as conditions.
...Fix up trivial conflict in security/tomoyo/realpath.c
11 Jul, 2011
1 commit
-
Sync with Linus' tree to be able to apply pending patches that
are based on newer code already present upstream.
09 Jul, 2011
1 commit
-
Since ca5ecddf (rcu: define __rcu address space modifier for sparse)
rcu_dereference_check use rcu_read_lock_held as a part of condition
automatically so callers do not have to do that as well.Signed-off-by: Michal Hocko
Acked-by: Paul E. McKenney
Signed-off-by: Jiri Kosina
30 Jun, 2011
1 commit
27 Jun, 2011
5 commits
-
The 'encrypted' key type defines its own payload format which contains a
symmetric key randomly generated that cannot be used directly to mount
an eCryptfs filesystem, because it expects an authentication token
structure.This patch introduces the new format 'ecryptfs' that allows to store an
authentication token structure inside the encrypted key payload containing
a randomly generated symmetric key, as the same for the format 'default'.More details about the usage of encrypted keys with the eCryptfs
filesystem can be found in the file 'Documentation/keys-ecryptfs.txt'.Signed-off-by: Roberto Sassu
Acked-by: Gianluca Ramunno
Acked-by: Tyler Hicks
Signed-off-by: Mimi Zohar -
This patch introduces a new parameter, called 'format', that defines the
format of data stored by encrypted keys. The 'default' format identifies
encrypted keys containing only the symmetric key, while other formats can
be defined to support additional information. The 'format' parameter is
written in the datablob produced by commands 'keyctl print' or
'keyctl pipe' and is integrity protected by the HMAC.Signed-off-by: Roberto Sassu
Acked-by: Gianluca Ramunno
Acked-by: David Howells
Signed-off-by: Mimi Zohar -
Some debug messages have been added in the function datablob_parse() in
order to better identify errors returned when dealing with 'encrypted'
keys.Changelog from version v4:
- made the debug messages more understandableSigned-off-by: Roberto Sassu
Acked-by: Gianluca Ramunno
Signed-off-by: Mimi Zohar -
Valid key type prefixes for the parameter 'key-type' are: 'trusted' and
'user'.Signed-off-by: Roberto Sassu
Acked-by: Gianluca Ramunno
Acked-by: David Howells
Signed-off-by: Mimi Zohar -
Do not dump the master key if an error is encountered during the request.
Signed-off-by: Roberto Sassu
Acked-by: Gianluca Ramunno
Signed-off-by: Mimi Zohar
22 Jun, 2011
1 commit
-
Fix error handling in construct_key_and_link().
If construct_alloc_key() returns an error, it shouldn't pass out through
the normal path as the key_serial() called by the kleave() statement
will oops when it gets an error code in the pointer:BUG: unable to handle kernel paging request at ffffffffffffff84
IP: [] request_key_and_link+0x4d7/0x52f
..
Call Trace:
[] request_key+0x41/0x75
[] cifs_get_spnego_key+0x206/0x226 [cifs]
[] CIFS_SessSetup+0x511/0x1234 [cifs]
[] cifs_setup_session+0x90/0x1ae [cifs]
[] cifs_get_smb_ses+0x34b/0x40f [cifs]
[] cifs_mount+0x13f/0x504 [cifs]
[] cifs_do_mount+0xc4/0x672 [cifs]
[] mount_fs+0x69/0x155
[] vfs_kern_mount+0x63/0xa0
[] do_kern_mount+0x4d/0xdf
[] do_mount+0x63c/0x69f
[] sys_mount+0x88/0xc2
[] system_call_fastpath+0x16/0x1bSigned-off-by: David Howells
Acked-by: Jeff Layton
Signed-off-by: Linus Torvalds
18 Jun, 2011
1 commit
-
____call_usermodehelper() now erases any credentials set by the
subprocess_inf::init() function. The problem is that commit
17f60a7da150 ("capabilites: allow the application of capability limits
to usermode helpers") creates and commits new credentials with
prepare_kernel_cred() after the call to the init() function. This wipes
all keyrings after umh_keys_init() is called.The best way to deal with this is to put the init() call just prior to
the commit_creds() call, and pass the cred pointer to init(). That
means that umh_keys_init() and suchlike can modify the credentials
_before_ they are published and potentially in use by the rest of the
system.This prevents request_key() from working as it is prevented from passing
the session keyring it set up with the authorisation token to
/sbin/request-key, and so the latter can't assume the authority to
instantiate the key. This causes the in-kernel DNS resolver to fail
with ENOKEY unconditionally.Signed-off-by: David Howells
Acked-by: Eric Paris
Tested-by: Jeff Layton
Signed-off-by: Linus Torvalds
14 Jun, 2011
1 commit
-
Don't return EAGAIN to keyctl_assume_authority() to indicate that a key could
not be found (ENOKEY is only returned if a negative key is found). Instead
return ENOKEY in both cases.Signed-off-by: David Howells
Signed-off-by: James Morris
28 May, 2011
1 commit
-
* 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs:
Create Documentation/security/, move LSM-, credentials-, and keys-related files from Documentation/ to Documentation/security/, add Documentation/security/00-INDEX, and update all occurrences of Documentation/ to Documentation/security/.
27 May, 2011
1 commit
-
Since this cred was not created with copy_creds(), it needs to get
initialized. Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
can lead to a NULL deref. Thanks to Robert for finding this.But introduced by commit 47a150edc2a ("Cache user_ns in struct cred").
Signed-off-by: Serge E. Hallyn
Reported-by: Robert Święcki
Cc: David Howells
Cc: stable@kernel.org (2.6.39)
Signed-off-by: Linus Torvalds
24 May, 2011
1 commit
20 May, 2011
1 commit
-
move LSM-, credentials-, and keys-related files from Documentation/
to Documentation/security/,
add Documentation/security/00-INDEX, and
update all occurrences of Documentation/
to Documentation/security/.
08 May, 2011
1 commit
-
The rcu callback user_update_rcu_disposal() just calls a kfree(),
so we use kfree_rcu() instead of the call_rcu(user_update_rcu_disposal).Signed-off-by: Lai Jiangshan
Signed-off-by: Paul E. McKenney
Acked-by: David Howells
Reviewed-by: Josh Triplett
17 Mar, 2011
2 commits
-
Make request_key() and co. return an error for a negative or rejected key. If
the key was simply negated, then return ENOKEY, otherwise return the error
with which it was rejected.Without this patch, the following command returns a key number (with the latest
keyutils):[root@andromeda ~]# keyctl request2 user debug:foo rejected @s
586569904Trying to print the key merely gets you a permission denied error:
[root@andromeda ~]# keyctl print 586569904
keyctl_read_alloc: Permission deniedDoing another request_key() call does get you the error, as long as it hasn't
expired yet:[root@andromeda ~]# keyctl request user debug:foo
request_key: Key was rejected by serviceSigned-off-by: David Howells
Signed-off-by: James Morris -
Improve /proc/keys by:
(1) Don't attempt to summarise the payload of a negated key. It won't have
one. To this end, a helper function - key_is_instantiated() has been
added that allows the caller to find out whether the key is positively
instantiated (as opposed to being uninstantiated or negatively
instantiated).(2) Do show keys that are negative, expired or revoked rather than hiding
them. This requires an override flag (no_state_check) to be passed to
search_my_process_keyrings() and keyring_search_aux() to suppress this
check.Without this, keys that are possessed by the caller, but only grant
permissions to the caller if possessed are skipped as the possession check
fails.Keys that are visible due to user, group or other checks are visible with
or without this patch.Signed-off-by: David Howells
Signed-off-by: James Morris
08 Mar, 2011
2 commits
-
Add a keyctl op (KEYCTL_INSTANTIATE_IOV) that is like KEYCTL_INSTANTIATE, but
takes an iovec array and concatenates the data in-kernel into one buffer.
Since the KEYCTL_INSTANTIATE copies the data anyway, this isn't too much of a
problem.Signed-off-by: David Howells
Signed-off-by: James Morris -
Add a new keyctl op to reject a key with a specified error code. This works
much the same as negating a key, and so keyctl_negate_key() is made a special
case of keyctl_reject_key(). The difference is that keyctl_negate_key()
selects ENOKEY as the error to be reported.Typically the key would be rejected with EKEYEXPIRED, EKEYREVOKED or
EKEYREJECTED, but this is not mandatory.Signed-off-by: David Howells
Signed-off-by: James Morris