dun/munge

MUNGE (MUNGE Uid 'N' Gid Emporium) is an authentication service for creating and validating user credentials.

MUNGE Uid 'N' Gid Emporium

MUNGE (MUNGE Uid 'N' Gid Emporium) is an authentication service for creating and validating user credentials. It is designed to be highly scalable for use in an HPC cluster environment. It provides a portable API for encoding the user's identity into a tamper-proof credential that can be obtained by an untrusted client and forwarded by untrusted intermediaries within a security realm. Clients within this realm can create and validate credentials without the use of root privileges, reserved ports, or platform-specific methods.

• Overview
• Installation Guide
• License Information
• Man Pages
• Verifying Releases

munge's Issues

munge service doesn't work after fresh RPM install prior to reboot

I built and installed munge for SLES12 using the spec file. The install went fine, but when I went to start the service (prior to reboot) it failed due to:

purge-head12:~ # journalctl -xn | tail
May 27 14:37:46 datawarp-head12 munged[29102]: munged: Error: Failed to check
pidfile dir "/var/run/munge": cannot canonicalize "/var/run/munge": No such
file or directory

I believe this is a result of not doing the following (from https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines ):

If you expect this file / directory to be available after package installation
(and before reboot), remember to add in your package %post :

systemd-tmpfiles --create /usr/lib/tmpfiles.d/<file_name>

add munged --max-ttl option to override maximum allowable time-to-live

What new or enhanced feature are you proposing?

Add a --max-ttl command-line option to munged.

What goal would this enhancement help you achieve?

This would allow munged to override the default maximum allowable time-to-live value (MUNGE_MAXIMUM_TTL) for decoding a credential. Reducing the maximum allowable time-to-live will limit the maximum growth of munged's replay cache. This is viable if clocks within the MUNGE realm can be kept in sync with minimal skew.

Please provide any additional information below.

When munged decodes a credential, it must maintain this state until the credential has expired in order to prevent it from being replayed. Decoded credentials are stored in the replay cache. This is currently implemented as a chained hash. Expired credentials are purged every 60 seconds (MUNGE_REPLAY_PURGE_SECS). If munged is decoding credentials at a sustained high rate, the replay cache will consume an increasing amount of memory with decreasing performance.

Original issue reported on code.google.com by chris.m.dunlap on 6 Mar 2014 at 6:21

Cannot start Munge: Logfile is insecure: invalid ownership of "/"

Hi

I was using Munge for my minicluster consisting of one head and 8 nodes. It was working fine with 3 nodes. then the other ones arrived and I have set them up.

Now i wanted to check if SLURM is working properly on all nodes. but somehow I cannot start MUNGE

 * Starting MUNGE munged                                                                                           [fail] 
munged: Error: Logfile is insecure: invalid ownership of "/"

when i change the log file chown to root it tells me it should be owned by uid=120, ok so changed it back with chown munge munge.log

I don't know what happened so that munge won't run, nothing munge relative has been changes.

log file is empty

Thanks in advance

Original issue reported on code.google.com by [email protected] on 14 Apr 2014 at 9:11

specifying CFLAGS at configure-time nullifies --enable-debug option

What steps will reproduce the problem?

./configure --enable-debug CFLAGS='-DGIDS_DEBUG'

What is the expected output? What do you see instead?

CFLAGS arising from --enable-debug should be appended to those explicitly set at configure-time. In addition, NDEBUG should not be defined.

$ egrep ^CFLAGS Makefile
CFLAGS = -DGIDS_DEBUG -Wall -Werror -pedantic -g

$ grep NDEBUG config/config.h
/* #undef NDEBUG */

Instead, CFLAGS from --enable-debug are omitted and NDEBUG is defined.

$ egrep ^CFLAGS Makefile
CFLAGS = -DGIDS_DEBUG

$ grep NDEBUG config/config.h
#define NDEBUG 1

What version of the software are you using? On what operating system?

munge-0.5.9
Debian squeeze/sid 2.6.32-5-amd64

Original issue reported on code.google.com by chris.m.dunlap on 6 Jan 2011 at 11:44

SystemD file does not honor sbindir

When configuring munge with

./configure \
    --prefix=/usr \
    --sbindir=/usr/bin  \
    --localstatedir=/var  \
    --sysconfdir=/etc

the SystemD file residing under /usr/lib/systemd/system/munge.service still contains ExecStart=/usr/sbin/munged

add option to call mlockall in munged

We've found it useful in our environment to have munged lock its pages upon startup because our compute nodes are often subject to extreme memory and disk pressure. Without locking, munged sometimes gets swapped out and cannot respond to requests quickly enough. This causes the resource manager (slurm in our case) to believe that compute nodes are down when they really aren't.

I've written a patch (attached) that adds an option (-M, --mlockall) to munged so that it will lock pages on startup. It works well in our environment, so I thought it might be useful to others.

0001-Add-mlockall-option-to-munged.patch.gz

Original issue reported on code.google.com by michaelfenn87 on 22 Apr 2013 at 4:26

munged can deadlock if clients block while sending data

What steps will reproduce the problem?

Have at least N clients (i.e., any user of libmunge) block while writing to the MUNGE unix domain socket, where N is the number of worker threads spawned by munged (the default is 2).

What is the expected output? What do you see instead?

munged should respond to new client requests. But if enough clients block while sending request data (where "enough" is defined as the number of worker threads), munged will stop responding to requests while continuing to accept new client connections.

What version of the software are you using? On what operating system?

munge-0.5.9
chaos-release-4.3-1.ch4.3
Red Hat Enterprise Linux Server release 5.4 (Tikanga)

Please provide any additional information below.

A given client request is handled by a munged worker thread. The worker reads each client request in two parts: the request header (containing the length of the request body), followed by the request body. [src/libcommon/m_msg.c:m_msg_recv()]

The read is performed by src/libcommon/fd.c:fd_read_n(), which keeps reading until either n bytes have been read or an error/eof occurs.

A timeout value needs to be specified for reading a client request.

Original issue reported on code.google.com by chris.m.dunlap on 12 Jul 2010 at 10:55

munged vulnerable to HMAC validation timing attack

What is a brief explanation of the security vulnerability?

The use of memcmp for HMAC validation can leak timing information, thereby allowing an adversary to iteratively try HMAC values, time the responses, and progressively deduce the correct HMAC value.

What is the impact, including how an attacker could exploit this?

The attack would allow for the forging of a single credential which must be completed within the credential's TTL (5 minutes by default). It would allow an adversary to rewrite the embedded UID/GID to enable privilege escalation via some other service using MUNGE for authentication. This attack would be more efficient than a brute-force attack against the entire key space.

What can be done to mitigate the attack?

Replace the memcmp used for HMAC validation with an implementation that compares the two memory regions in an amount of time that is independent of their contents.

What version of the software are you using? On what operating system?

munge-0.5.10

Please provide any additional information below.
Attach any patches, proof-of-concept, or exploit code.

Reported by Jon Bringhurst.

Original issue reported on code.google.com by chris.m.dunlap on 22 Jul 2013 at 10:12

cannot start daemon

What steps will reproduce the problem?

I installed (configure, make, make install) munge as admin, because it did not allow me to install it as non-admin user. Checked permission of /var/log/munge and /var/lib/munge - both of them are owned by 'root'.

When I try to start the daemon using /usr/sbin/munged as admin, it gives munged: Error: Logfile is insecure: "/var/log/munge/munged.log" should be owned by uid=0, when tried as non-admin user it gives the following error, munged: Error: Cannot check logfile "/var/log/munge/munged.log": Permission denied.

What should I do?

What version of the software are you using? On what operating system?

munge-0.5.10

Original issue reported on code.google.com by diamcode on 3 Feb 2012 at 8:58

Contribution of systemd files

Hi !

Attached are two files to allow munge to be started on systems using systemd.

munged.service.gz
munged-tmpfiles.conf.gz

munged.service starts the service.
munged-tmpfiles.conf takes care of creating the /var/run/munge directory.

In principal these can be shared across other distributions using systemd so it makes sense to ship them with munge itself.

Please could you add to a contrib directory or something.

Many Thanks

Steve.

(Fedora 17 will use these)

Original issue reported on code.google.com by s.traylen on 5 Feb 2012 at 11:01

Munge service unable to start, incorrect permissions

I am installing munge and cannot get it started on any of our worker nodes. It generates this error when attempting to run munged
Error: Logfile is insecure: "/var/log/munge/munged.log" should be owned by UID 0
I followed the install guide to set the correct permissions, however the error still persists. It does appear that this issue has been common previously, but none of the solutions fix the issue. Using --force produces the error
munged: Warning: Logfile is insecure: "/var/log/munge/munged.log" should be owned by UID 0 munged: Warning: Logfile is insecure: invalid ownership of "/var/log/munge"

Installation options

FYI,

You might want to also mention FreeBSD ports and pkgsrc on

https://github.com/dun/munge/wiki/Installation-Guide

On FreeBSD, munge can be installed with

pkg install munge

or

cd /usr/ports/security/munge && make install

On NetBSD:

pkgin install munge

cd /usr/pkgsrc/security/munge && make install

As pkgsrc is cross-platform, the last command can be used on just about any POSIX platform. I use pkgsrc to deploy munge and hundreds of other packages on CentOS.

Cheers,

Jason

Failed to access "/usr/local/var/run/munge/munge.socket.2 No such file or directory (err=6)

Hello. I can't run the basic tests of munge as referred to in InstallationGuide

What steps will reproduce the problem?

munge -n

What is the expected output? What do you see instead?

No error should be displayed

Instead:

munge: Error: Failed to access "/usr/local/var/run/munge/munge.socket.2": No such file or directory

What version of the software are you using? On what operating system?

0.5.11. CentOS 6

Please provide any additional information below.

mycomputer:Munge username$ /etc/init.d/munge status
munged (pid  5937) is running...

Installation was done as root but then chown'd to my username.

Any suggestions for further debugging would be appreciated. I expect the defect is with the user rather than the system...

Thank you.

James

Original issue reported on code.google.com by jamesresearching on 25 Nov 2014 at 9:38

Add --pid-file command-line option to munged

Attached is a patch against 0.5.11 which adds the possibility to specify the pid-file to used by munged. Our particular use-case is with Slurm when using different munge-keys (and consequently simultaneously running munged's) for the slurmdbd and the cluster-internal communication. Possibly it is useful for others as well.

munge-0.5.11-specify-pidfile.patch.gz

Original issue reported by Daniel Ahlin [email protected] on 2 Mar 2015

VPATH builds fail to install init script

What steps will reproduce the problem?

$ cd /tmp/foo
$ /home/dun/dvl/munge/configure --prefix=/tmp/munge
$ make -s install

What is the expected output? What do you see instead?

A successful installation into /tmp/munge is expected; instead, the following error occurs:

/usr/bin/install: cannot stat `/home/dun/dvl/munge/src/etc/munge.init': No such file or directory

What version of the software are you using? On what operating system?

munge-0.5.9
Debian squeeze/sid 2.6.32-5-amd64

Please provide any additional information below.

On Linux, the error is lost in the make output and installation continues. On OpenBSD, the error is fatal and installation terminates:

$ make -s install
Making install in src
Making install in etc
install: /home/dun/dvl/munge/src/etc/munge.init: No such file or directory
*** Error code 71

Stop in /tmp/foo/src/etc (line 458 of Makefile).
*** Error code 1

Stop in /tmp/foo/src/etc (line 313 of Makefile).
*** Error code 1

Stop in /tmp/foo/src (line 337 of Makefile).
*** Error code 1

Stop in /tmp/foo (line 378 of Makefile).

Original issue reported on code.google.com by chris.m.dunlap on 14 Jan 2011 at 3:44

pkgconfig file install error with custom prefix

What steps will reproduce the problem?

Add %define _prefix /opt/slurm to munge.spec and build with rpmbuild.

What is the expected output? What do you see instead?

Expected output is a set of RPMs built with /opt/slurm as the prefix. Actual output has this error:

[   17s] RPM build errors:
[   17s]     File not found by glob: 
/var/tmp/cray-munge-0.5.11/opt/munge/lib64/pkgconfig/*.pc

What version of the software are you using? On what operating system?

0.5.11 SLES 11 SP2

Please provide any additional information below.

I believe this is an error in src/etc/Makefile.am around this line:

if test -d "$(libdir)/pkgconfig"; then \

Following my example, /opt/slurm/lib64/pkgconfig doesn't exist so the file never gets installed. The script should take this into account.

Original issue reported on code.google.com by sheepweevil on 16 Oct 2013 at 10:09

specify network interface for obtaining origin IP address

What new or enhanced feature are you proposing?

Support for specifying which network interface munged will use when obtaining the origin IP address to embed within the credential metadata.

What goal would this enhancement help you achieve?

This would allow a client to obtain a credential from a multihomed host such that the embedded origin IP address is relevant to the credential recipient.

Original issue reported on code.google.com by chris.m.dunlap on 18 Jul 2013 at 6:44

systemd-tmpfiles munge.conf installed but unpackaged on SLES11, breaks rpmbuild

What steps will reproduce the problem?

The systemd-tmpfiles munge.conf needs to be excluded from older (hello SLES11) rpm builds in the spec file as it causes rpmbuild to fail.

aelwell@iTDS:~/compile> rpmbuild -ta ./munge-0.5.11.tar.bz2

What is the expected output? What do you see instead?

Requires(postun): /bin/sh
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit)
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/munge-0.5.11
error: Installed (but unpackaged) file(s) found:
   /usr/lib/tmpfiles.d/munge.conf

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/tmpfiles.d/munge.conf

What version of the software are you using? On what operating system?

munge-0.5.11 on SLES11

Please provide any additional information below.

Reported by andrew.elwell in #11.

Original issue reported on code.google.com by chris.m.dunlap on 19 Dec 2013 at 12:18

munged: Error: Logfile is insecure: group-writable permissions set on "/var/log"

What steps will reproduce the problem?

Start munged on Ubuntu 14.04 without use of the --force command-line option.

What is the expected output? What do you see instead?

munged should start with the default options. Instead, it fails and exits:

$ sudo service munge start
 * Starting MUNGE munged [fail]
munged: Error: Logfile is insecure: group-writable permissions set on "/var/log"

What version of the software are you using? On what operating system?

munge-0.5.11 on Ubuntu 14.04

Please provide any additional information below.

Ubuntu 14.04 changes the /var/log directory permissions from 0755 root:root to 0775 root:syslog. munged is warning of the group-writable permissions on /var/log.

Running munged with either the --force or --syslog command-line option will override this warning:

• --force will override errors (turning them into warnings) for an existing local domain socket, a lack of entropy for the PRNG, and some potentially insecure file/directory permissions
• --syslog will bypass the permission check on /var/log since log messages will instead be routed to the syslog service

These command-line options can be specified in the OPTIONS variable in /etc/default/munge:

OPTIONS="--force"

https://bugs.launchpad.net/ubuntu/+source/munge/+bug/1287624

Original issue reported on code.google.com by chris.m.dunlap on 29 May 2014 at 8:00

Please expand repo description

Include is an authentication service for creating and validating credentials. in the repo description so it shows up on third-party sites, like: https://code.gov/#/explore-code/agencies/DOE

Unable to query group info: Numerical result out of range

What steps will reproduce the problem?

Create a group in /etc/group with ~500 users.

What is the expected output? What do you see instead?

munged should be able to process groups without error. Instead, the following message is logged:

Error: Unable to query group info: Numerical result out of range

This error occurs when processing a group of 482 users on aztec. Further processing of the group file is halted at this point, resulting in subsequent groups being ignored.

What version of the software are you using? On what operating system?

munge-0.5.10

$ lsb_release -a
LSB 
Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:
printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.2 (Santiago)
Release:    6.2
Codename:   Santiago

Please provide any additional information below.

The processing of group membership is done in _gids_hash_create(). This routine iterates over the groups with xgetgrent() which encapsulates getgrent_r(). A buffer is dynamically allocated via xgetgrent_buf_create() and passed to xgetgrent(). The size of this buffer is determined by _xgetgrent_get_buf_size() which calls sysconf(_SC_GETGR_R_SIZE_MAX). This particular system returns a sysconf value of 1024. In the past, this value proved insufficient for our systems so MINIMUM_GR_BUF_SIZE was defined to set a minimum buffer size of 4096.

Group entries are obtained by repeatedly calling xgetgrent(). This particularly large group causes xgetgrent() to fail with ERANGE ("Numerical result out of range"). It requires a buffer size of at least 7424.

Original issue reported on code.google.com by chris.m.dunlap on 7 Jun 2012 at 1:07

support for transitioning to a new key (aka key rotation)

What new or enhanced feature are you proposing?

Support for transitioning to a new key.

What goal would this enhancement help you achieve?

Each munged currently supports a single cryptographic key. If a group of hosts needs to transition to a new key, there will be a time interval where some hosts have transitioned to the new key while other hosts are still using the old key. Support is needed to allow authentication between hosts during this time interval where both the old and new keys are valid. Furthermore, after this time interval has elapsed, the old key needs to be (automatically) marked invalid.

Requested by Flux: because signed jobs in the queue might sit there for a long time and be invalidated if we had to change the munge key.

Original issue reported on code.google.com by chris.m.dunlap on 9 Jan 2013 at 8:42

munge install to user-defined prefix

Hello,

I accidentally tried to post to "User Discussion" google group. Sorry for that.

The problem is following: when I try to install munge to the empty prefix it fails with the following error below. Attached file highlights the problematic place in the build system. Currently munge searches systemd directory in the prefix and if there is no such directory it switches to the default /lib/systemd/system which is not accessible for the regular user. Most of the prefix installations would be empty so this breaks them.

Installation error:

/usr/bin/install: cannot create regular file '/lib/systemd/system/munge.service': Permission denied
make[3]: *** [install-data-local] Error 1
make[3]: Leaving directory `/home/artpol/WORK/Development/SLURM/mpi_plugin/src/munge-patch/munge-0.5.11_old/src/etc'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/artpol/WORK/Development/SLURM/mpi_plugin/src/munge-patch/munge-0.5.11_old/src/etc'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/artpol/WORK/Development/SLURM/mpi_plugin/src/munge-patch/munge-0.5.11_old/src'
make: *** [install-recursive] Error 1

munge-0.5.11_prefix_install.patch.gz

Original issue reported on code.google.com by artpol84 on 10 Oct 2014 at 9:46

munged always denies credentials

Built MUNGE 0.5.10 (and .9) on a CentOS 5 system. Ran the munged. The munge -n | unmunge test results in lt-unmunge: Error: Invalid credential

Built MUNGE on an Ubuntu system, and copied it to the CentOS. Works fine. readelf shows that the same libraries are being used in both cases.

I've tried different compilers to no avail.

Original issue reported on code.google.com by arroosen on 18 Mar 2011 at 9:42

permission problems: used to work

I had munge working, basic tests across my machines worked. For some reason, it doesn't work any more and complains on ownership issues of the log file. Specifically,

/var/log/munge is owned by munge and gives the following error

/etc/init.d/munge start
 * Starting MUNGE munged
   ...fail!
munged: Error: Logfile is insecure: invalid ownership of "/var/log/munge"

if I change ownership to root, I get the following ,,,

 * Starting MUNGE munged
   ...fail!
munged: Error: Failed to open logfile "/var/log/munge/munged.log": Permission denied

I am surprised as this used to work ... who should own /var/log/munge?

What version of the software are you using? On what operating system?

0.5.11 on ubuntu 14.04

Original issue reported on code.google.com by hsundar on 16 Oct 2014 at 10:13

munge won't start

Hello,

I'm a total newbie an i need munge for testing slurm.

I installed munge according to the InstallationGuide with the the following command:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var && make && make install

When i try to invoke the daemon the following error appears:

munged: Error: Logfile is insecure: invalid ownership of "/var/log/munge"

When i try to test the Installation with remunge or munge -n the following error appears:

munge: Error: Unable to access "/var/run/munge/munge.socket.2": No such file or directory 

I'm using mung-0.5.10 and the OS i'm using is openSuse 11.3 on a Virtual Machine (VBox-Host: Win7)

Hope somebody can help me.

Original issue reported on code.google.com by MarcNowak83 on 11 May 2011 at 7:51

ACL in munged ?

Hello,

Sorry if it's not the correct place to ask those kind of question.

I've got a slurm cluster using munge authentication with an associated "cluster" network. The master and submit node have a public network interface so that users can connect with ssh and submitting jobs. Everything is working fine.

I also have a bunch of external machines with only a public interface. Ultimately, I'd like people to have root access on them and still let them submit batch job on the cluster. Since they are root, they can create a local user with the same uid as valid user on the cluster and impersonate him. Obviously, this is not something we want.

I'm far from being a munge and slurm expert. From what I understand, I'd like to have some kind of ACL mechanisms within munged to express something like :

• all request from this ip / network can only request data related to this list of users (or map any requests to a single user in my very specific use case)

Or maybe having multiple munge keys with ACL regarding user information allowed to be requested with it (only the key is used as a valid token, no need to express ip restriction).

Maybe there a completely different solution or a simpler workaround I don't see ?

I would be interested to have your opinion on this.

What would be the right place for a solution for this problem ? Auth plugin within slurm ? Some
kind of ACLs in munge and/or multiple key mechanism ?

Contribution of SELinux security policy

What new or enhanced feature are you proposing?

Defining a MUNGE SELinux security policy.

What goal would this enhancement help you achieve?

An SELinux security policy is missing from the munge rpm in Red Hat EPEL.

With an initial SELinux policy for defining a security domain, one can put that domain into permissive mode to see what is required to use the software.

This makes it possible to use MUNGE on an SELinux enabled system, as one can put a single domain into permissive mode to observe what permissions are required for the full functionality.

Please provide any additional information below.

With SELinux, each process runs in a domain which determines its access rights with respect to other domains. The policy defines a domain munge_t in which the munge daemon as well as the user commands run (automatic domain transition on execution of the binaries), and provides minimal permissions the daemon needs to start. The working directories in /var/run belong to the domain munge_var_run_t. This assumes that SELinux runs the Red Hat targeted policy.

munge.te.gz
munge.if.gz
munge.fc.gz

Contributed by Cezary Sliwa <[email protected]>.

References:
https://wiki.centos.org/HowTos/SELinux

Original issue reported on code.google.com by chris.m.dunlap on 3 Apr 2014 at 5:52

Init script needs "Default-Start" on SuSE 11

I built RPMs from the latest release (0.5.10). When I tried to install them, it failed when trying to enable the service for startup. Manually trying to turn on the service, it also failed:

# chkconfig munge on
insserv: Script munge is broken: incomplete LSB comment.
insserv: missing `Default-Start:'  entry: please add even if empty.
insserv: exiting now!
/sbin/insserv failed, exit code 1

The OpenSuSE packaging guide (https://en.opensuse.org/openSUSE:Packaging_init_scripts) implies that we need to add a Default-Start and Default-Stop line.

I'm not sure what the "defaults" should be, but adding something like:

# Default-Start:      2 3 5
# Default-Stop:

between the ### BEGIN INIT INFO and ### END INIT INFO lines seems to fix the problem.

Original issue reported on code.google.com by [email protected] on 23 Aug 2011 at 7:34

munged is unable to restart if previous daemon did not shutdown gracefully

What steps will reproduce the problem?

killall -9 munged; munged

What is the expected output? What do you see instead?

After the old munged process has been killed, a new munged process should be able to run. Instead, the new munged process exits with the error Found existing socket "/var/run/munge/munge.socket.2".

What version of the software are you using? On what operating system?

munge-0.5.10

Please provide any additional information below.

This error occurs because the old process did not shutdown gracefully, and as such, did not unlink its unix domain socket. The new process finds the existing socket and exits since that socket could be in use by another munged process currently running.

There are several ways in which munged can be prevented from shutting down gracefully: a node could kernel panic, or be power-cycled via powerman, the BMC, or other means. If munged is invoked with the --force command-line option (or if this option is specified in the DAEMON_ARGS in /etc/{default,sysconfig}/munge), the old socket will be unlinked and a new socket will be created. But a new munged process should be capable of recovering from this situation without being "forced", while maintaining the ability to detect whether an existing socket is currently in use.

Reported by Don Albert at Bull.com on 2012-03-16.

Original issue reported on code.google.com by chris.m.dunlap on 18 Mar 2012 at 4:48

make dist-bzip2 broken

Having installed the latest commit from master, which fixed a problem with the specs file, I installed munge, with make && make install

Next, I need to make an rpm, for xCAT to use in provisioning. So I ran
make dist-bzip2 PACKAGE=munge VERSION=0.5.11

This produces a tar.bz2 file, but when I try to run rpmbuild against it;
rpmbuild -tb --clean munge-0.5.11.tar.bz2
I get an error;
error: File /home/jbberry/slurm/munge/V0.5.11/munge-0.5.11.tar.xz: No such file or directory

munged is uninterruptible and consumes cpu on FreeBSD 8.2 & 9.0

What steps will reproduce the problem?

Run munged on FreeBSD 8.2 or later.

What is the expected output? What do you see instead?

munged should consume negligible cpu when idle, and gracefully terminate upon receipt of a SIGTERM. Instead, munged consumes an entire cpu and must be forcibly terminated with a SIGKILL.

What version of the software are you using? On what operating system?

munge-0.5.10 on FreeBSD 8.2 & 9.0

Please provide any additional information below.

This bug was introduced by 501d7a1.

This behavior can be averted by running munged with --group-update-time=-1.

Original issue reported on code.google.com by chris.m.dunlap on 26 Sep 2012 at 12:21

munged crashes when processing supplementary group info under glibc

What steps will reproduce the problem?

Add the following to /etc/passwd (this would never exist in production, but is used to emulate the fact that ldap groups can have case insensitive users defined in them)

dummy1:x:9999:9999::/tmp:/bin/false
Dummy1:x:9999:9999::/tmp/bin/false

to /etc/group

dummy:x:9999:dumm1,Dummy1

What is the expected output? What do you see instead?

munge should run and not crash. Munge will crash.

What version of the software are you using? On what operating system?

I have tried EPEL 0.5.8 (x86_64) and self built 0.5.9 (x86_64,i386) with identical results under Centos 5.5.

Please provide any additional information below.

Munge was quitting without any warning after 1 hour of running. The only clue in the logs was when it started it spit out an ...

2010-10-27 20:21:21 Error:     Unable to query group info: Permission denied

Tracing the source it became obvious that munge can not handle the possibility that the same uid is mapped to two different strings, including case insensitivity. The fix for the most obvious issues should be as simple as altering the user comparison to a stricmp, but that does not fix the silent crash of munge during some edge cases and a group info reload.

Original issue reported on code.google.com by ericew on 28 Oct 2010 at 12:35

add munge --uid --gid options for compat with kernel key retention svcs

It is possible to conveniently generate (root) munge creds from within the linux kernel using the kernel's request_key() api.

One adds a line like this to /etc/request-key.conf:

create  user    munge   *       |/usr/bin/munge

Then in the kernel calls:

key = request_key(&key_type_user, "munge", "");
...

It should be possible to generate munge creds for non-root users like this:

create  user    munge    *      |/usr/bin/munge --uid %u --gid %g

if munge grew those arguments. The /sbin/request-key user mode helper runs as root, but the %u and %g macros are set to the fsuid and fsgid of the kernel context that called request_key().

I have two 9p-related uses for this feature:

1. 9nbd is a network block device based on 9P which can reconnect when a server is rebooted. To reconnect from the kernel it needs to obtain a munge credential. I have it working now with the auth user hardwired to root. The auth user ought to be configurable.
2. For the full 9p file system client, each user establishes its own "fid space" that is separately authenticated. The way we do it now is to initially authenticate as root, then presume that subsequent claims of identity are true (without a credential) because they are coming in on the same tcp connection. With this feature, each user could present credentials.

I am going to implement a wrapper that parses those arguments, calls setregid/setreuid, then calls munge. If munge could do that directly for root only, there would be one less wrapper in the world.

Original issue reported on code.google.com by garlick.jim on 11 Jul 2012 at 11:58

change spec file to use munge.service and tmpfiles.d for systemd

What steps will reproduce the problem?

Boot a SLES 12 system with the munge service file enabled.

What is the expected output? What do you see instead?

Expected output is the munge service starting successfully.

What we see is munge fails to come up with

Oct 22 16:18:46 nid00002 munged[10601]: munged: Error: Failed to check pidfile dir "/var/run/munge": cannot canonicalize "/var/run/munge": No such file or directory

What version of the software are you using? On what operating system?

Munge 0.5.11 on SLES 12.

Please provide any additional information below.

In our environment systemd removes /var/run/munge before starting services, so it's missing when munged tries to start. Using this as a guide:

https://blog.hqcodeshop.fi/archives/93-Handling-varrun-with-systemd.html

I added a few lines to munge.service to fix the problem.

PermissionsStartOnly=true
ExecStartPre=-/usr/bin/mkdir -m 0755 -p /var/run/munge
ExecStartPre=-/usr/bin/chown -R munge:munge /var/run/munge

Original issue reported on code.google.com by dcgloe on 23 Oct 2014 at 8:23

"test a == b" is not portable across shells

What version of the software are you using? On what operating system?

MUNGE 0.5.10
NetBSD i386 6_BETA

patch-config_x__ac__arch.m4.gz
patch-configure.gz

Original issue reported on code.google.com by [email protected] on 19 Feb 2012 at 1:42

rpmbuild fails on cents 7

Hi,

I'm trying to install munge on a centos 7 machine and get the following:

...
Requires(post): /bin/sh
Requires(postun): /bin/sh
Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) rtld(GNU_HASH)
Processing files: munge-debuginfo-0.5.11-1.el7.centos.x86_64
Provides: munge-debuginfo = 0.5.11-1.el7.centos munge-debuginfo(x86-64) = 0.5.11-1.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/munge-0.5.11-1.el7.centos.x86_64
error: Installed (but unpackaged) file(s) found:
   /usr/lib/systemd/system/munge.service
   /usr/lib/tmpfiles.d/munge.conf


RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/systemd/system/munge.service
   /usr/lib/tmpfiles.d/munge.conf

Any ideas there?

Thanks

Error starting munged

I am trying to start munge daemon using /usr/sbin/munged and it gives me the following error:

munged: Error: Found pid 13595 bound to socket "/var/run/munge/munge.socket.2"

I executed /usr/sbin/munged once before this without any error, but on trying munge -n in gave me the error:

munge: Error: Unable to access "/var/run/munge/munge.socket.2": No such file or directory

So, I executed /usr/sbin/munged again and it gave me the first error mentioned.

I am using Fedora 20 on VirtualBox

Hope someone can help me solve this!

Original issue reported on code.google.com by marathe.monica on 5 Nov 2014 at 9:39

libmunge.so.2: cannot open shared object file: No such file or directory

Hi,

When I run /usr/sbin/munged, it show error as below.

error while loading shared libraries: libmunge.so.2: cannot open shared object file: No such file or directory

br

Ring

Original issue reported on code.google.com by [email protected] on 27 Jul 2011 at 2:00

Installed (but unpackaged) file(s) found: munge.service & munge.conf

What steps will reproduce the problem?

Attempt to build an rpm from the 0.5.11 tarball:

$ rpmbuild -ta munge-0.5.11.tar.bz2

What is the expected output? What do you see instead?

rpmbuild fails with the following errors:

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/systemd/system/munge.service
   /usr/lib/tmpfiles.d/munge.conf

What version of the software are you using? On what operating system?

munge-0.5.11 on RHEL7

Please provide any additional information below.

Reported by JERPoser in #8.

Possibly the same as #27.

Original issue reported on code.google.com by chris.m.dunlap on 5 Aug 2014 at 12:04

IPv6 support

What new or enhanced feature are you proposing?

IPv6 support.

What goal would this enhancement help you achieve?

This would allow an IPv6 address for the credential origin to be stored in the metadata when the credential is encoded, and queried when the credential is decoded.

Please provide any additional information below.

Request from Tomas Kouba on 2013-02-06:
https://groups.google.com/forum/?fromgroups=#!topic/munge-users/dzqNuKT9uww

Original issue reported on code.google.com by chris.m.dunlap on 11 Feb 2013 at 9:23

munge

libmissing symbols may conflict with other libraries

We have an issue on Trinity with linking an application with both liblustreapi and libmunge. It turns out both libraries are exporting the strlcpy symbol. IMO neither library should be exporting a symbol that doesn't belong to the library.

Can you namespace all the symbols provided by libmissing? Maybe something like libmissing_strlcpy, libmissing_strlcat, etc. This will prevent future symbol conflicts. We do something similar in Open MPI. If function x is needed and not available we define opal_x and #define x opal_x in an internal header.

Logfile overrun by "Failed to query password file entry for user"

It is the one below in ./src/munged/gids.c

log_msg (LOG_INFO,
      "Failed to query password file entry for \"%s\"", user);
return (-1);

We use the same group file on every system, but only the subset of the users that needs access to the system appear in passwd, so this particular error causes a lot of output (~3.5MB/hour).

I'm just going to remove it and recompile, but it might be nice to have that error only output with a debug option or there be an option to disable info level logging or something else that seems reasonable to you. Thanks,

Stephen

Original issue reported on code.google.com by [email protected] on 23 Oct 2013 at 7:05

No munge.socket.2 file

I've compiled munge myself and there was no reported error during configuration, make or make install. I'm using an ubuntu virtual machine on VirtualBox. The host OS is Mac OS X.

When I try to test the installation using the command

munge -n

I get the following error:

munge: Error: Failed to access "/var/run/munge/munge.socket.2": No such file or directory

There is indeed no /var/run/munge/munge.socket.2 file, but I don't know what this file should be. Should it have been created by installing Munge? Or should I have created it myself and if the answer is yes, which command should I run to get it created?

Thanks in advance.

Erica

Original issue reported on code.google.com by ericaflriello on 31 Jul 2014 at 8:09

munged timer thread running amok and consuming cpu

What steps will reproduce the problem?

Not consistently reproducible. This is occurring on a cluster of ~1944 nodes (sierra), of which <1% are exhibiting this behavior after boot. This reportedly started after upgrading the cluster to CHAOS 5.

What is the expected output? What do you see instead?

munged is expected to use minimal cpu time. Instead, top shows it consuming as much of a core as it can. Attaching to the process with strace shows repeated stat()s of /etc/group:

13:50:27.956403 stat("/etc/group", {st_dev=makedev(0, 19), st_ino=8006, 
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=104, st_size=49948, st_atime=2012/05/21-13:05:58, 
st_mtime=2012/05/21-11:05:01, st_ctime=2012/05/21-13:05:29}) = 0

13:50:27.956457 stat("/etc/group", {st_dev=makedev(0, 19), st_ino=8006, 
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=104, st_size=49948, st_atime=2012/05/21-13:05:58, 
st_mtime=2012/05/21-11:05:01, st_ctime=2012/05/21-13:05:29}) = 0

13:50:27.956507 stat("/etc/group", {st_dev=makedev(0, 19), st_ino=8006, 
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=104, st_size=49948, st_atime=2012/05/21-13:05:58, 
st_mtime=2012/05/21-11:05:01, st_ctime=2012/05/21-13:05:29}) = 0

What version of the software are you using? On what operating system?

munge-0.5.10

$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.2 (Santiago)

$ grep "model name" /proc/cpuinfo | sort -u
model name      : Intel(R) Xeon(R) CPU           X5660  @ 2.80GHz

$ uname -a
Linux sierra972 2.6.32-220.13.1.2chaos.ch5.x86_64 #1 SMP Thu Apr 19 12:15:29 
PDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.

The LWP in question can be identified with either top or ps. After attaching to the running process with gdb, info threads identifies this LWP as the timer thread. Selecting this thread (thread 4) and stepping through execution shows _gids_update() (where the stat() of /etc/group occurs). At the end of _gids_update(), a new timer is scheduled for 1 hour from now. Execution then returns to an inner loop of timer_thread() that dispatches expired timer events. This inner loop continues while active timers exist that have expired. The current time (set in ts_now immediately before this loop via timer_get_timespec() which calls gettimeofday()) is far in the future (year 2052!), so the next _gids_update() timer is immediately dispatched, which sets a new _gids_update() timer which is immediately dispatched, ad infinitum (or at least until sometime in 2052, at which point it may sort itself out).

(gdb) print ts_now
$1 = {tv_sec = 2604158256, tv_nsec = 519236000}

(gdb) print time(0)
$2 = 1337732647

A couple of other nodes in this state show ts_now.tv_sec values of 2604574221 and 2604574458.

Original issue reported on code.google.com by chris.m.dunlap on 23 May 2012 at 9:56

syslog support and/or ability to specify minimum priority level for logging

What new or enhanced feature are you proposing?

Allow messages logged by munged to be forwarded to syslog, and/or support specifying the minimum priority level for messages to be logged.

What goal would this enhancement help you achieve?

Syslog support would allow for logs to be forwarded to a centralized server. Specification of a minimum priority level would allow informational messages to be suppressed if so desired.

Please provide any additional information below.

Request from Graham Van Heule at LANL on 2012-03-27:

We're wondering if there is an option to reduce the logging level of munge or
have it send to syslog so that we can forward the logs to a diskful systems.

Original issue reported on code.google.com by chris.m.dunlap on 28 Mar 2012 at 11:56

munged does not work on IPv6-only hosts - unable to resolve host

What steps will reproduce the problem?

Configure host to be IPv6-only and start munged.

What is the expected output? What do you see instead?

munged should work on hosts configured for IPv4 and/or IPv6. But on IPv6-only hosts, munged is unable to resolve its hostname:

# /etc/init.d/munge start
Starting MUNGE: mungedmunged: Error: Unable to resolve host "foo"
                                                           [FAILED]

What version of the software are you using? On what operating system?

munge-0.5.10

Please provide any additional information below.

All of the MUNGE communications are over a local Unix domain socket, and as such, are unaffected by IPv6.

But when munged starts, it calls gethostname() to obtain the hostname, and gethostbyname() to resolve its IPv4 address. This IPv4 address is embedded into the metadata when encoding credentials.

Since the IP address here is not strictly required for authentication, munged should treat a hostname resolution failure as a warning and continue its execution using an IPv4 address of 0.0.0.0.

Reported by Tomas Kouba on 2013-02-08.

Original issue reported on code.google.com by chris.m.dunlap on 11 Feb 2013 at 8:01

rpmbuild errors

Hi related to #36 I am experiencing a similar issue :
On Centos 7.1.1503 I am trying to build an RPM package using the command

rpmbuild -tb --clean munge-0.5.11.tar.bz2
and it fails with the following :

error: Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system/munge.service
/usr/lib/tmpfiles.d/munge.conf

Is there any update on the 0.5.12 release please?

Cheers.

munge.spec for openSUSE

Hi,

the package bzip2-devel does not exist under openSUSE or SLES products. the package that contains the bzlib.h file is named libbz2-devel.

1] Some informations:

openSUSE# cat /etc/SuSE-release 
openSUSE 11.2 (x86_64)
VERSION = 11.2
openSUSE# rpmbuilt -ta munge-0.5.9.tar.bz2
error: Failed build dependencies:
    bzip2-devel is needed by munge-0.5.9-1.src
openSUSE# rpm -ql libbz2-devel
/usr/include/bzlib.h
/usr/lib64/libbz2.so

2] Here is the modification I made to munge.spec to have it build on openSUSE 11.2:

openSUSE# diff munge.spec.orig munge.spec
13d12
< BuildRequires:    bzip2-devel
14a14,22
> 
> %if 0%{?fedora_version}
> BuildRequires:    bzip2-devel
> %endif
> 
> %if 0%{?suse_version}
> BuildRequires:    libbz2-devel
> %endif
> 

It is not really an issue but it could help someone else running munge on SUSE systems... maybe a line in the README file could be sufficient.

Cheers,
Matthieu

Original issue reported on code.google.com by timhaute on 2 Feb 2011 at 11:00