fiorix/go-daemon

Utility to "daemonize" Go programs

go-daemon's Issues

How to stop service?

New release with fix from #8

Set up an automated release system and release new version with fix from #8.

go program keeps logfile open

I have a trivial go program:

package main

import (
        "log"
        "time"
)

func main() {
        for {
                log.Print("Hello.")
                time.Sleep(1 * time.Second)
        }
}

When I run this with god with the logfile option, the go program also gets a file descriptor for the log file. When the log file is rotated, the go program keeps the old file descriptor. It logs to the new log file, but this prevents the old file from being deleted by the OS until the go program is restarted.

This is because you open the logfile, then fork. The child process inherits the open file descriptor.

Privilege escalation due to weak privdrop

this issue is related to #4 but focuses more on the privdrop. In order to make a correct privdrop you need to set more then the effective uid/gid. Using setresuid and setresgid.

From the research:
There is a pretty good paper regarding this: http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf

They did a reference implementation:

The implementation uses setresuid
if available since it has the clearest semantics and
it is able to set each of the user IDs independently

From The Man Page:

Setting the effective user (group) ID to the saved set-user-ID (saved
set-group-ID) is possible since Linux 1.1.37 (1.1.38). On an
arbitrary system one should check _POSIX_SAVED_IDS.
Under glibc 2.0 seteuid(euid) is equivalent to setreuid(-1, euid) and
hence may change the saved set-user-ID. Under glibc 2.1 and later it
is equivalent to setresuid(-1, euid, -1) and hence does not change
the saved set-user-ID. Analogous remarks hold for setegid(), with
the difference that the change in implementation from setregid(-1,
egid) to setresgid(-1, egid, -1) occurred in glibc 2.2 or 2.3
(depending on the hardware architecture).
According to POSIX.1, seteuid() (setegid()) need not permit euid
(egid) to be the same value as the current effective user (group) ID,
and some implementations do not permit this.

Important section:
Under glibc 2.1 and later it is equivalent to setresuid(-1, euid, -1) and hence does not change the saved set-user-ID.

Support reloading of go binary

It'd be very useful if go-daemon supported re-loading of go binary to ease updating.

Currently, only way to update the currently running go binary is.

• overwrite the old go binary with the updated one.
• kill go-daemon
• re-launch go-daemon with new binary.

Proposed solution:

• go-daemon receives SIGUSR[12] or SIGWINCH.
• go-daemon kills current child(who's exec()-ing old go binary)
• go-daemon re-loads updated go binary and re-exec().

Security: Missing call to initgroups/setgroups

I notice when dropping privileges, supplementary groups are not dropped:
https://github.com/fiorix/go-daemon/blob/master/god.c#L160

I've not been able to confirm but this would mean the process retain supplementary groups such as "wheel", and "admin". Only the primary group is dropped. This would allow the process continued access to /var/log and other potentially sensitive areas.

A call to initgroups(user_pwd, getegid()) should be made after setegid() to replace supplementary groups with the specified primary group and the supplementary of the specified user. Alternatively, setgroups(NULL, 0) will wipe the supplementary list but usually it's desirable to maintain supplementary groups of the requested user.

Daemon stops running when started in a ssh pseudo-terminal

If I ssh into a server and start a daemon everything works fine.

1. ssh in.
2. run daemon
   • $ sudo god -r / -n -l /tmp/test.log -p /tmp/test.pid -- sleep 100
3. logout
4. check if process is still running ... success.

However if I use a pseudo terminal with SSH the process fails:

1. ssh command:
   • $ ssh -t user@myhost "sudo god -r / -n -l /tmp/test.log -p /tmp/test.pid -- sleep 100"
2. check if process is still running ... fail