From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KEYS: Provide KEYCTL_GRANT_PERMISSION
Date: Tue, 09 Jul 2019 20:42:25 +0000 [thread overview]
Message-ID: <20190709204225.GM641@sol.localdomain> (raw)
In-Reply-To: <155862712317.24863.13455329541359881229.stgit@warthog.procyon.org.uk>
On Thu, May 23, 2019 at 04:58:43PM +0100, David Howells wrote:
> Provide a keyctl() operation to grant/remove permissions. The grant
> operation, wrapped by libkeyutils, looks like:
>
> int ret = keyctl_grant_permission(key_serial_t key,
> enum key_ace_subject_type type,
> unsigned int subject,
> unsigned int perm);
>
> Where key is the key to be modified, type and subject represent the subject
> to which permission is to be granted (or removed) and perm is the set of
> permissions to be granted. 0 is returned on success. SET_SECURITY
> permission is required for this.
>
> The subject type currently must be KEY_ACE_SUBJ_STANDARD for the moment
> (other subject types will come along later).
>
> For subject type KEY_ACE_SUBJ_STANDARD, the following subject values are
> available:
>
> KEY_ACE_POSSESSOR The possessor of the key
> KEY_ACE_OWNER The owner of the key
> KEY_ACE_GROUP The key's group
> KEY_ACE_EVERYONE Everyone
>
> perm lists the permissions to be granted:
>
> KEY_ACE_VIEW Can view the key metadata
> KEY_ACE_READ Can read the key content
> KEY_ACE_WRITE Can update/modify the key content
> KEY_ACE_SEARCH Can find the key by searching/requesting
> KEY_ACE_LINK Can make a link to the key
> KEY_ACE_SET_SECURITY Can set security
> KEY_ACE_INVAL Can invalidate
> KEY_ACE_REVOKE Can revoke
> KEY_ACE_JOIN Can join this keyring
> KEY_ACE_CLEAR Can clear this keyring
>
> If an ACE already exists for the subject, then the permissions mask will be
> overwritten; if perm is 0, it will be deleted.
>
> Currently, the internal ACL is limited to a maximum of 16 entries.
>
> For example:
>
> int ret = keyctl_grant_permission(key,
> KEY_ACE_SUBJ_STANDARD,
> KEY_ACE_OWNER,
> KEY_ACE_VIEW | KEY_ACE_READ);
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Where is the documentation and tests for this? I want to add syzkaller
definitions for this, but there is no documentation (a commit message doesn't
count). I checked the 'next' branch of keyutils as well.
How is anyone supposed to use this if there is no documentation?
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KEYS: Provide KEYCTL_GRANT_PERMISSION
Date: Tue, 9 Jul 2019 13:42:25 -0700 [thread overview]
Message-ID: <20190709204225.GM641@sol.localdomain> (raw)
In-Reply-To: <155862712317.24863.13455329541359881229.stgit@warthog.procyon.org.uk>
On Thu, May 23, 2019 at 04:58:43PM +0100, David Howells wrote:
> Provide a keyctl() operation to grant/remove permissions. The grant
> operation, wrapped by libkeyutils, looks like:
>
> int ret = keyctl_grant_permission(key_serial_t key,
> enum key_ace_subject_type type,
> unsigned int subject,
> unsigned int perm);
>
> Where key is the key to be modified, type and subject represent the subject
> to which permission is to be granted (or removed) and perm is the set of
> permissions to be granted. 0 is returned on success. SET_SECURITY
> permission is required for this.
>
> The subject type currently must be KEY_ACE_SUBJ_STANDARD for the moment
> (other subject types will come along later).
>
> For subject type KEY_ACE_SUBJ_STANDARD, the following subject values are
> available:
>
> KEY_ACE_POSSESSOR The possessor of the key
> KEY_ACE_OWNER The owner of the key
> KEY_ACE_GROUP The key's group
> KEY_ACE_EVERYONE Everyone
>
> perm lists the permissions to be granted:
>
> KEY_ACE_VIEW Can view the key metadata
> KEY_ACE_READ Can read the key content
> KEY_ACE_WRITE Can update/modify the key content
> KEY_ACE_SEARCH Can find the key by searching/requesting
> KEY_ACE_LINK Can make a link to the key
> KEY_ACE_SET_SECURITY Can set security
> KEY_ACE_INVAL Can invalidate
> KEY_ACE_REVOKE Can revoke
> KEY_ACE_JOIN Can join this keyring
> KEY_ACE_CLEAR Can clear this keyring
>
> If an ACE already exists for the subject, then the permissions mask will be
> overwritten; if perm is 0, it will be deleted.
>
> Currently, the internal ACL is limited to a maximum of 16 entries.
>
> For example:
>
> int ret = keyctl_grant_permission(key,
> KEY_ACE_SUBJ_STANDARD,
> KEY_ACE_OWNER,
> KEY_ACE_VIEW | KEY_ACE_READ);
>
> Signed-off-by: David Howells <dhowells@redhat.com>
Where is the documentation and tests for this? I want to add syzkaller
definitions for this, but there is no documentation (a commit message doesn't
count). I checked the 'next' branch of keyutils as well.
How is anyone supposed to use this if there is no documentation?
- Eric
next prev parent reply other threads:[~2019-07-09 20:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 15:58 [PATCH 0/2] keys: ACLs David Howells
2019-05-23 15:58 ` David Howells
2019-05-23 15:58 ` [PATCH 1/2] KEYS: Replace uid/gid/perm permissions checking with an ACL David Howells
2019-05-23 15:58 ` David Howells
2019-07-10 1:15 ` Eric Biggers
2019-07-10 1:15 ` Eric Biggers
2019-07-10 1:35 ` Eric Biggers
2019-07-10 1:35 ` Eric Biggers
2019-07-30 3:49 ` Eric Biggers
2019-07-30 3:49 ` Eric Biggers
2019-07-31 1:16 ` Eric Biggers
2019-07-31 1:16 ` Eric Biggers
2019-08-07 2:58 ` Eric Biggers
2019-08-07 2:58 ` Eric Biggers
2019-08-14 22:41 ` Eric Biggers
2019-08-14 22:41 ` Eric Biggers
2019-08-27 19:18 ` [PATCH keys-next] keys: Fix permissions assigned to anonymous session keyrings Eric Biggers
2019-08-27 19:18 ` Eric Biggers
2019-05-23 15:58 ` [PATCH 2/2] KEYS: Provide KEYCTL_GRANT_PERMISSION David Howells
2019-05-23 15:58 ` David Howells
2019-07-09 20:42 ` Eric Biggers [this message]
2019-07-09 20:42 ` Eric Biggers
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=20190709204225.GM641@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.