-
Notifications
You must be signed in to change notification settings - Fork 54
security
diod uses MUNGE for authentication.
Briefly, a MUNGE credential is a user's uid and gid plus optional payload,
encrypted using a secret shared between client and server, then base64
encoded.
Although 9P contains a framework for external authentication, it seemed
more straightforward to simply pass the MUNGE credential in as the value
of the uname= mount option on the client (v9fs) side.
A 9P attach message is generated at mount time containing this credential
in the uname field.
If the initial authenticated attach is successful, subsequent attach
messages on the same socket without MUNGE credentials are accepted,
provided they originate from the same user name, or the original user was root.
When a file system is mounted with
diodmount host:path dir
v9fs receives the following mount options:
access=user,uname=<root MUNGE cred>
In this mode, root is authenticated at mount time, and each new user that accesses the file system is introduced with a new attach, without credential, but since the original attach was root, it is accepted.
On server side, requests can be associated by fid with the original
attach. The setfsuid(2), setfsgid(2), and setgroups(2) system calls
are used to change the identity of the server work crew thread (running as
root) before handling a particular I/O request. The host file system then
accepts or denies the request based on this identity.
When a file system is mounted with
diodmount -p -u user host:path dir
v9fs receives the following mount options:
access=<uid of user>,uname=<user MUNGE cred>
Other users are unconditionally denied access to the file system by the client so only the initial attach is required.
In this mode the server can actually run all the time as the user.
diodmount arranges this by first contacting the diodctl superserver,
requesting that it run an instance of the diod server for user and
obtaining a port to contact it on. The new diod server drops its root
privileges, then only accepts attach messages from user.
It is worth mentioning that modern Linux kernels implement private
file system namespaces similar to those described in
The Use of Name Spaces in Plan 9
by Pike et al.
With linux unshare system calls in the right places, it is possible to have
multiple users sharing a compute node, each with a private set of diod
mounts that are unmounted implicitly when their job terminates.
The diodctl superserver implements a 9P synthetic file system.
Its purpose is to spawn private instances of diod on demand that can
be shared across multiple clients. diodctl runs as root and accepts MUNGE
authentication just like diod. It contains three synthetic files:
ctl, server, and exports.
diodmount requests a private server for user by:
- mounting the
diodctlfile system, which generates a MUNGE-authenticated attach for user - writing "new" to ctl
- reading the port number of the private server from server
- mounting the private server as user
The "new" request is a no-op if a server is already running as user.
Otherwise, diodctl spawns an instance of diod as root, passing user's
uid on its command line. diod drops its root identity and becomes
uid, then awaits mount requests.
The exports file simply provides a mechanism for diodmount to list the
available exports. In the future, other synthetic files may be added to
diodctl, e.g. to facilitate performance monitoring or batch system
management of I/O resources.
In addition to MUNGE authentication, diod and diodctl access can be
limited by a configurable listen address list, configurable file system
exports, and TCP wrapper support.