From: Eric Biggers <ebiggers3@gmail.com>
To: keyrings@vger.kernel.org
Subject: [PATCH] KEYS: fix in-kernel documentation for keyctl_read()
Date: Thu, 26 Oct 2017 20:54:58 +0000 [thread overview]
Message-ID: <20171026205458.105299-1-ebiggers3@gmail.com> (raw)
From: Eric Biggers <ebiggers@google.com>
When keyctl_read() is passed a buffer that is too small, the behavior is
inconsistent. Some key types will fill as much of the buffer as
possible, while others won't copy anything. Moreover, the in-kernel
documentation contradicted the man page on this point.
Update the in-kernel documentation to say that this point is
unspecified.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
Documentation/security/keys/core.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 1266eeae45f6..16f196069721 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -628,12 +628,12 @@ The keyctl syscall functions are:
defined key type will return its data as is. If a key type does not
implement this function, error EOPNOTSUPP will result.
- As much of the data as can be fitted into the buffer will be copied to
- userspace if the buffer pointer is not NULL.
-
- On a successful return, the function will always return the amount of data
- available rather than the amount copied.
+ On success, the function will return the amount of data placed into the
+ buffer.
+ If the specified buffer is too small, then the size of the buffer required
+ will be returned, and it is unspecified whether any data will be copied
+ into the buffer.
* Instantiate a partially constructed key::
--
2.15.0.rc2.357.g7e34df9404-goog
next reply other threads:[~2017-10-26 20:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 20:54 Eric Biggers [this message]
2017-11-01 13:57 ` [PATCH] KEYS: fix in-kernel documentation for keyctl_read() David Howells
2017-11-01 23:22 ` Eric Biggers
2017-11-02 0:06 ` 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=20171026205458.105299-1-ebiggers3@gmail.com \
--to=ebiggers3@gmail.com \
--cc=keyrings@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.