File: README

package info (click to toggle)
munge 0.5.8-7
  • links: PTS
  • area: main
  • in suites: lenny
  • size: 2,628 kB
  • ctags: 1,064
  • sloc: ansic: 13,400; sh: 9,746; makefile: 325
file content (57 lines) | stat: -rw-r--r-- 3,259 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
INTRODUCTION

  MUNGE (MUNGE Uid 'N' Gid Emporium) is an authentication service for creating
  and validating credentials.  It is designed to be highly scalable for use
  in an HPC cluster environment.  It allows a process to authenticate the
  UID and GID of another local or remote process within a group of hosts
  having common users and groups.  These hosts form a security realm that is
  defined by a shared cryptographic key.  Clients within this security realm
  can create and validate credentials without the use of root privileges,
  reserved ports, or platform-specific methods.


RATIONALE

  The need for MUNGE arose out of the HPC cluster environment.  Consider the
  scenario in which a local daemon running on a login node receives a client
  request and forwards it on to remote daemons running on compute nodes within
  the cluster.  Since the user has already logged on to the login node, the
  local daemon just needs a reliable means of ascertaining the UID and GID
  of the client process.  Furthermore, the remote daemons need a mechanism to
  ensure the forwarded authentication data has not been subsequently altered.

  A common solution to this problem is to use Unix domain sockets to
  determine the identity of the local client, and then forward this
  information on to remote hosts via trusted rsh connections.  But this
  presents several new problems.  First, there is no portable API for
  determining the identity of a client over a Unix domain socket.  Second,
  rsh connections must originate from a reserved port; the limited number
  of reserved ports available on a given host directly limits scalability.
  Third, root privileges are required in order to bind to a reserved port.
  Finally, the remote daemons have no means of determining whether the
  client identity is authentic.


OVERVIEW

  A process creates a credential by requesting one from the local
  MUNGE service.  The encoded credential contains the UID and GID of
  the originating process.  This process sends the credential to another
  process within the security realm as a means of proving its identity.
  The receiving process validates the credential with the use of its local
  MUNGE service.  The decoded credential provides the receiving process with
  a reliable means of ascertaining the UID and GID of the originating process.
  This information can be used for accounting or access control decisions.

  The contents of the credential (including any optional payload data) are
  encrypted with a key shared by all munged daemons within the security realm.
  The integrity of the credential is ensured by a message authentication
  code (MAC).  The credential is valid for a limited time defined by
  its time-to-live (TTL).  The daemon ensures unexpired credentials
  are not replayed on a particular host.  Decoding of a credential can
  be restricted to a particular user and/or group ID.  The payload data
  can be used for purposes such as embedding the destination's address to
  ensure the credential is only valid on a specific host.  The internal
  format of the credential is encoded in a platform-independent manner.
  And the credential itself is base64 encoded to allow it to be transmitted
  over virtually any transport.