All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.