Follow standard Unix daemon practices

jgarzik commented at 7:36 am on August 11, 2014: contributor

fork() + setsid() is too minimal, and does not follow standard daemonize protocol. Normal steps include http://stackoverflow.com/questions/3095566/linux-daemonize

Implementation comments:

we do output data to stdout/stderr upon some error conditions, so /dev/null might not be the best choice (or it might be, if we just change a few things!)
would be nice to achieve chroot-ability. That would likely break anybody with crazy symlinking schemes.

Code ref: https://github.com/bitcoin/bitcoin/blob/master/src/bitcoind.cpp#L122

jgarzik added the label Improvement on Aug 11, 2014

laanwj commented at 8:36 am on August 11, 2014: member

-daemonize is indeed a hack, but I wouldn’t be for adding code to extend it.

On modern systems all of this is handled by the service manager, for example upstart or systemd. The daemonizing functionality of the service itself is not used. Doing chrooting, setuid-ing and such properly is non-trivial and needs a lot of testing. So this is prefereably handled in one place and correctly.

Edit: to be clear, I’m not arguing against doing -daemonize properly. However I don’t want to burden bitcoind with ‘system set up’ functionality such as chrooting, setuid, and such.

jgarzik commented at 1:33 pm on August 11, 2014: contributor

no one said anything about setuid(). setuid() introduces new security issues. setuid() has little to do with chroot()
as long as bitcoind file use is confined to $datadir, chroot() works. That is the function of chroot(), to limit the scope of your filesystem access beyond point X. Standard security principle of least-access / dropping privs you don’t need.
it is not correct that “On modern systems all of this is handled by the service manager, for example upstart or systemd” Startup scripts invoke the equivalent of the “-daemon” option in other projects, to handle the steps listed at [1]

systemd is a different layer on top of that.

There are valid security reasons for all the steps listed at [1], and missing steps reduces security [ever so slightly].

[1] http://stackoverflow.com/questions/3095566/linux-daemonize

laanwj commented at 3:27 pm on August 11, 2014: member

Cannot you just chroot before starting bitcoind? I really don’t like extending bitcoind with more and more ancillary features (that can be handled by other tools or the system).

sipa commented at 3:52 pm on August 11, 2014: member

No opinion on where this functionality belongs, but chrooting() before starting bitcoind at least requires having the bitcoind binary and all its shared libraries inside the chroot environment.

laanwj commented at 3:58 pm on August 11, 2014: member

Right, that would be an advantage to doing it in-process.

I’m just afraid of feature creep. It’s easy to say yes to one more thing. But if we start adding all kinds of unix daemon specific features, why not windows-specific features, or Mac specific features. And it all needs testing and maintenance (on different flavors of Unix, I’d suppose). We need to define limits to what is part of Bitcoin Core’s responsibility.

jgarzik commented at 4:08 pm on August 11, 2014: contributor

Correct. Typically you read shared libs and other files needed outside the jail, then you reduce privs. That most easily happens in-process. Same pattern as several other “reduced privileges after point X in program” security measures.

laanwj added the label Priority Low on Aug 11, 2014

jwilkins commented at 6:02 am on February 26, 2015: none

https://lkml.org/lkml/2007/9/25/434 and http://misc.openbsd.narkive.com/UrTwzZcc/chroot-ssh-users#post17

cheako commented at 3:45 am on April 20, 2015: none

@jwilkins Chaining root requires UID zero. Using chroot against a file breaks the root user out of the chroot, but for normal users it does not. If the chroot has no files or no suid root binaries then it can be an effective jail for processes with EUID && UID != 0. Though it was never intended to do so, it’s just a by-product. @all Bitcoin and chroot has other issues, the ability to write to files and even worse write permissions on a directory. The effectiveness of a chroot is limited until these are addressed.

Though it’s not entirely necessary to have daemons support changing euid/uid/root/ect. I use daemon for that.

Closing the terminal(pty/tty) is important as not doing so can cause ssh sessions to be unable to close cleanly.

I also suggest looking at http://libslack.org/daemon/manpages/daemon.1.html as [1] looks a little barren in comparison.

laanwj removed the label Priority Low on Dec 6, 2017

Sjors commented at 7:30 pm on March 16, 2018: member

Did #8813 fix this?

jgarzik commented at 3:42 pm on November 4, 2019: contributor

Did #8813 fix this? @Sjors Did not fix, but moved the needle forward, at least. Closing as sufficient + probably won’t see further action.

jgarzik closed this on Nov 4, 2019

MarcoFalke locked this on Dec 16, 2021

Follow standard Unix daemon practices #4676