From: Andrew Morton <akpm@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: torvalds@osdl.org, keyrings@linux-nfs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Keys: Add possessor permissions to keys
Date: Wed, 21 Sep 2005 10:15:58 -0700 [thread overview]
Message-ID: <20050921101558.7ad7e7d7.akpm@osdl.org> (raw)
In-Reply-To: <12434.1127314090@warthog.cambridge.redhat.com>
David Howells <dhowells@redhat.com> wrote:
>
>
> The attached patch adds extra permission grants to keys for the possessor of a
> key in addition to the owner, group and other permissions bits. This makes
> SUID binaries easier to support without going as far as labelling keys and key
> targets using the LSM facilities.
>
> This patch adds a second "pointer type" to key structures (struct key_ref *)
> that can have the bottom bit of the address set to indicate the possession of
> a key. This is propagated through searches from the keyring to the discovered
> key. It has been made a separate type so that the compiler can spot attempts
> to dereference a potentially incorrect pointer.
The above bit needs to be captured in a code comment. Because:
> ...
> /*
> + * key reference with possession flag handling
> + */
> +static inline struct key_ref *key_mkref(const struct key *key, unsigned long possession)
> +{
> + return (struct key_ref *) ((unsigned long) key | possession);
> +}
Is hair-raising and makes people want to come after you with a stick ;)
(And an 80-col xterm)
ugh, I see. `struct key_ref' doesn't actually exist anywhere. The code
only ever deals with pointers to this non-existent structure and they are
munged `struct key *'s.
Did this _have_ to happen?
> + }
> + else if (key->uid == context->fsuid) {
Documentation/CodingStyle?
> + "%s;%d;%d;%08x;%s",
> + key_deref(key)->type->name,
> + key_deref(key)->uid,
> + key_deref(key)->gid,
> + key_deref(key)->perm,
> + key_deref(key)->description ? key_deref(key)->description : ""
> );
This doesn't actually make things clear.
> + if (PTR_ERR(key_ref) != -EAGAIN) {
> + if (IS_ERR(key_ref))
> + key = key_deref(key_ref);
> + else
> + key = ERR_PTR(PTR_ERR(key_ref));
> + break;
> + }
> + }
That's getting a bit intimate with how IS_ERR and PTR_ERR are implemented
but I guess we're unlikely to change that.
This all seems quite inappropriate to -rc2?
next prev parent reply other threads:[~2005-09-21 17:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5378.1127211442@warthog.cambridge.redhat.com>
2005-09-21 14:48 ` [PATCH] Keys: Add possessor permissions to keys David Howells
2005-09-21 15:05 ` Linus Torvalds
2005-09-21 15:44 ` David Howells
2005-09-21 17:15 ` Andrew Morton [this message]
2005-09-21 17:47 ` Trond Myklebust
2005-09-21 18:36 ` David Howells
2005-09-21 18:29 ` David Howells
2005-09-21 18:45 ` Andrew Morton
2005-09-21 18:56 ` Linus Torvalds
2005-09-22 10:00 ` David Howells
2005-10-03 4:43 ` [Keyrings] " Kyle Moffett
2005-09-21 18:33 ` [PATCH] Keys: Add possessor permissions to keys [try #2] David Howells
2005-09-28 16:03 ` [PATCH] Keys: Add possessor permissions to keys [try #3] David Howells
2005-09-21 19:23 ` [PATCH] Keys: Add possessor permissions to keys James Morris
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=20050921101558.7ad7e7d7.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dhowells@redhat.com \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@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