From: David Howells <dhowells@redhat.com>
To: torvalds@osdl.org, akpm@linux-foundation.org, kwc@citi.umich.edu
Cc: arunsr@cse.iitk.ac.in, dwalsh@redhat.com,
linux-security-module@vger.kernel.org, dhowells@redhat.com,
linux-kernel@vger.kernel.org
Subject: [PATCH 1/3] KEYS: Allow clients to set key perms in key_create_or_update()
Date: Thu, 13 Mar 2008 19:14:32 +0000 [thread overview]
Message-ID: <20080313191432.28959.52722.stgit@warthog.procyon.org.uk> (raw)
The key_create_or_update() function provided by the keyring code has a default
set of permissions that are always applied to the key when created. This might
not be desirable to all clients.
Here's a patch that adds a "perm" parameter to the function to address this,
which can be set to KEY_PERM_UNDEF to revert to the current behaviour.
Signed-off-by: Arun Raghavan <arunsr@cse.iitk.ac.in>
Acked-by: David Howells <dhowells@redhat.com>
---
include/linux/key.h | 3 +++
security/keys/key.c | 18 ++++++++++--------
security/keys/keyctl.c | 3 ++-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/linux/key.h b/include/linux/key.h
index 163f864..8b0bd33 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -67,6 +67,8 @@ struct key;
#define KEY_OTH_SETATTR 0x00000020
#define KEY_OTH_ALL 0x0000003f
+#define KEY_PERM_UNDEF 0xffffffff
+
struct seq_file;
struct user_struct;
struct signal_struct;
@@ -232,6 +234,7 @@ extern key_ref_t key_create_or_update(key_ref_t keyring,
const char *description,
const void *payload,
size_t plen,
+ key_perm_t perm,
unsigned long flags);
extern int key_update(key_ref_t key,
diff --git a/security/keys/key.c b/security/keys/key.c
index 654d23b..d98c619 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -757,11 +757,11 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
const char *description,
const void *payload,
size_t plen,
+ key_perm_t perm,
unsigned long flags)
{
struct key_type *ktype;
struct key *keyring, *key = NULL;
- key_perm_t perm;
key_ref_t key_ref;
int ret;
@@ -806,15 +806,17 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
goto found_matching_key;
}
- /* decide on the permissions we want */
- perm = KEY_POS_VIEW | KEY_POS_SEARCH | KEY_POS_LINK | KEY_POS_SETATTR;
- perm |= KEY_USR_VIEW | KEY_USR_SEARCH | KEY_USR_LINK | KEY_USR_SETATTR;
+ /* if the client doesn't provide, decide on the permissions we want */
+ if (perm == KEY_PERM_UNDEF) {
+ perm = KEY_POS_VIEW | KEY_POS_SEARCH | KEY_POS_LINK | KEY_POS_SETATTR;
+ perm |= KEY_USR_VIEW | KEY_USR_SEARCH | KEY_USR_LINK | KEY_USR_SETATTR;
- if (ktype->read)
- perm |= KEY_POS_READ | KEY_USR_READ;
+ if (ktype->read)
+ perm |= KEY_POS_READ | KEY_USR_READ;
- if (ktype == &key_type_keyring || ktype->update)
- perm |= KEY_USR_WRITE;
+ if (ktype == &key_type_keyring || ktype->update)
+ perm |= KEY_USR_WRITE;
+ }
/* allocate a new key */
key = key_alloc(ktype, description, current->fsuid, current->fsgid,
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 56e963b..993be63 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -112,7 +112,8 @@ asmlinkage long sys_add_key(const char __user *_type,
/* create or update the requested key and add it to the target
* keyring */
key_ref = key_create_or_update(keyring_ref, type, description,
- payload, plen, KEY_ALLOC_IN_QUOTA);
+ payload, plen, KEY_PERM_UNDEF,
+ KEY_ALLOC_IN_QUOTA);
if (!IS_ERR(key_ref)) {
ret = key_ref_to_ptr(key_ref)->serial;
key_ref_put(key_ref);
next reply other threads:[~2008-03-13 19:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-13 19:14 David Howells [this message]
2008-03-13 19:14 ` [PATCH 2/3] KEYS: Don't generate user and user session keyrings unless they're accessed David Howells
2008-03-13 22:20 ` Andrew Morton
2008-03-14 2:30 ` David Howells
2008-03-13 19:14 ` [PATCH 3/3] KEYS: Make the keyring quotas controllable through /proc/sys David Howells
2008-03-13 22:28 ` Andrew Morton
2008-03-13 22:47 ` Andrew Morton
2008-03-14 2:30 ` David Howells
2008-03-14 2:39 ` David Howells
2008-03-14 11:46 ` David Howells
2008-03-19 0:04 ` Andrew Morton
2008-03-19 11:19 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080313191432.28959.52722.stgit@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arunsr@cse.iitk.ac.in \
--cc=dwalsh@redhat.com \
--cc=kwc@citi.umich.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®