munge(7) - f30

1
2MUNGE(7)                  MUNGE Uid 'N' Gid Emporium                  MUNGE(7)
3
4
5

NAME

7       munge - MUNGE overview
8
9

INTRODUCTION

11       MUNGE  (MUNGE  Uid  'N'  Gid Emporium) is an authentication service for
12       creating and validating credentials.  It is designed to be highly scal‐
13       able  for  use  in  an HPC cluster environment.  It allows a process to
14       authenticate the UID and GID of another local or remote process  within
15       a  group  of  hosts having common users and groups.  These hosts form a
16       security realm that is defined by a shared cryptographic key.   Clients
17       within  this security realm can create and validate credentials without
18       the use of root privileges, reserved ports, or platform-specific  meth‐
19       ods.
20
21

RATIONALE

23       The  need for MUNGE arose out of the HPC cluster environment.  Consider
24       the scenario in which a local daemon running on a login node receives a
25       client  request and forwards it on to remote daemons running on compute
26       nodes within the cluster.  Since the user has already logged on to  the
27       login  node, the local daemon just needs a reliable means of ascertain‐
28       ing the UID and GID of the client  process.   Furthermore,  the  remote
29       daemons  need  a  mechanism to ensure the forwarded authentication data
30       has not been subsequently altered.
31
32       A common solution to this problem is to  use  Unix  domain  sockets  to
33       determine  the  identity  of  the  local  client, and then forward this
34       information on to remote hosts via trusted rsh connections.   But  this
35       presents  several  new  problems.   First, there is no portable API for
36       determining the identity of a client over a Unix domain  socket.   Sec‐
37       ond,  rsh  connections must originate from a reserved port; the limited
38       number of reserved ports available on  a  given  host  directly  limits
39       scalability.  Third, root privileges are required in order to bind to a
40       reserved port.  Finally, the remote daemons have no means of  determin‐
41       ing  whether  the  client  identity  is authentic.  MUNGE solves all of
42       these problems.
43
44

USAGE

46       A process creates a credential by requesting one from the  local  MUNGE
47       service, either via the munge_encode() C library call or the munge exe‐
48       cutable.  The encoded credential contains the UID and GID of the origi‐
49       nating  process.   This process sends the credential to another process
50       within the security realm as a means  of  proving  its  identity.   The
51       receiving  process  validates  the credential with the use of its local
52       MUNGE service, either via the munge_decode()  C  library  call  or  the
53       unmunge  executable.   The  decoded  credential  provides the receiving
54       process with a reliable means of ascertaining the UID and  GID  of  the
55       originating  process.   This  information can be used for accounting or
56       access control decisions.
57
58

DETAILS

60       The contents of the credential (including any  optional  payload  data)
61       are  encrypted with a key shared by all munged daemons within the secu‐
62       rity realm.  The integrity of the credential is ensured  by  a  message
63       authentication  code (MAC).  The credential is valid for a limited time
64       defined by its time-to-live (TTL); this presumes clocks within a  secu‐
65       rity realm are in sync.  Unexpired credentials are tracked by the local
66       munged daemon in order to prevent  replay  attacks  on  a  given  host.
67       Decoding  of a credential can be restricted to a particular user and/or
68       group ID.  The payload data can be used for purposes such as  embedding
69       the  destination's  address to ensure the credential is only valid on a
70       specific host.  The internal format of the credential is encoded  in  a
71       platform-independent  manner.   And  the  credential  itself  is base64
72       encoded to allow it to be transmitted over virtually any transport.
73
74

AUTHOR

76       Chris Dunlap <cdunlap@llnl.gov>
77
78

COPYRIGHT

80       Copyright (C) 2007-2017 Lawrence Livermore National Security, LLC.
81       Copyright (C) 2002-2007 The Regents of the University of California.
82
83       MUNGE is free software: you can redistribute it and/or modify it  under
84       the  terms  of  the GNU General Public License as published by the Free
85       Software Foundation, either version 3  of  the  License,  or  (at  your
86       option) any later version.
87
88       Additionally  for the MUNGE library (libmunge), you can redistribute it
89       and/or modify it under the terms  of  the  GNU  Lesser  General  Public
90       License  as published by the Free Software Foundation, either version 3
91       of the License, or (at your option) any later version.
92
93