From: Stephen Hemminger <stephen@networkplumber.org>
To: dev@dpdk.org
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>,
Jakub Grajciar <jgrajcia@cisco.com>
Subject: [PATCH 7/7] doc: clarify memif secret is not access control
Date: Tue, 22 Sep 2026 12:40:58 -0700 [thread overview]
Message-ID: <20260922194138.508919-8-stephen@networkplumber.org> (raw)
In-Reply-To: <20260922194138.508919-1-stephen@networkplumber.org>
The secret option was described as a security option, which invites
using it as one. It is sent in cleartext in the connection request,
and when passed as a device argument it is visible to other local
users in the process arguments.
Describe it as what it is, a check against connecting mismatched
interfaces, and document what actually restricts access to an
interface. By default the control socket is in the abstract
namespace and has no filesystem entry to own or permission. Only
with socket-abstract=no do file permissions and the owner-uid and
owner-gid options apply.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Tested-by: Sriram Yagnaraman <sriram.yagnaraman@ericsson.com>
---
doc/guides/nics/memif.rst | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/doc/guides/nics/memif.rst b/doc/guides/nics/memif.rst
index f8b629ab1f..5552d319d0 100644
--- a/doc/guides/nics/memif.rst
+++ b/doc/guides/nics/memif.rst
@@ -47,9 +47,27 @@ client.
"owner-uid=1000", "Set socket listener owner uid. Only relevant to server with socket-abstract=no", "unchanged", "uid_t"
"owner-gid=1000", "Set socket listener owner gid. Only relevant to server with socket-abstract=no", "unchanged", "gid_t"
"mac=01:23:45:ab:cd:ef", "Mac address", "01:ab:23:cd:45:ef", ""
- "secret=abc123", "Secret is an optional security option, which if specified, must be matched by peer", "", "string len 24"
+ "secret=abc123", "Optional identifier which, if specified, must be matched by peer", "", "string len 24"
"zero-copy=yes", "Enable/disable zero-copy client mode. Only relevant to client, requires '--single-file-segments' eal argument", "no", "yes|no"
+**Access control**
+
+Any process able to connect to the socket of a server interface is able to
+reach its shared memory rings, so what restricts access to that socket is
+the security boundary.
+
+By default the socket is in the abstract namespace (``socket-abstract=yes``).
+An abstract socket has no filesystem entry.
+Use a network namespace to restrict access to such an interface.
+
+With ``socket-abstract=no`` the socket is a filesystem object and normal
+file permissions apply, together with the ``owner-uid`` and ``owner-gid``
+options.
+
+The ``secret`` option is *not* an access control mechanism.
+It only guards against connecting mismatched interfaces by mistake,
+for example where several interfaces share one socket.
+
**Connection establishment**
In order to create memif connection, two memif interfaces, each in separate
--
2.53.0
next prev parent reply other threads:[~2026-09-22 19:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 19:40 [PATCH 0/7] net/memif: validate input from connecting peer Stephen Hemminger
2026-09-22 19:40 ` [PATCH 1/7] maintainers: update for memif driver Stephen Hemminger
2026-09-22 19:40 ` [PATCH 2/7] net/memif: fix issues in statistics Stephen Hemminger
2026-09-22 19:40 ` [PATCH 3/7] net/memif: validate peer descriptors Stephen Hemminger
2026-09-22 19:40 ` [PATCH 4/7] net/memif: validate control channel requests Stephen Hemminger
2026-09-22 19:40 ` [PATCH 5/7] net/memif: validate descriptor length in zero-copy mode Stephen Hemminger
2026-09-22 19:40 ` [PATCH 6/7] net/memif: add server/client connectivity test Stephen Hemminger
2026-09-22 19:40 ` Stephen Hemminger [this message]
2026-09-24 15:44 ` [PATCH 7/7] doc: clarify memif secret is not access control Stephen Hemminger
2026-09-28 17:56 ` Stephen Hemminger
2026-09-24 11:24 ` [PATCH 0/7] net/memif: validate input from connecting peer Sriram Yagnaraman
2026-09-29 15:42 ` Stephen Hemminger
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=20260922194138.508919-8-stephen@networkplumber.org \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=jgrajcia@cisco.com \
--cc=sriram.yagnaraman@ericsson.com \
/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