Date: Mon, 6 Feb 2012 08:31:47 -0600 From: Guy Helmer <ghelmer@palisadesystems.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: Mikolaj Golub <trociny@FreeBSD.org>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Andrey Zonov <andrey@zonov.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r230869 - head/usr.sbin/daemon Message-ID: <1E1FA19C-7C4C-4288-B163-E33FC68D9837@palisadesystems.com> In-Reply-To: <20120205093938.GC30033@garage.freebsd.pl> References: <201202011641.q11Gf0j6095461@svn.freebsd.org> <20120204074201.GA1694@garage.freebsd.pl> <4F2CEB1D.10607@zonov.org> <27A0A960-F767-4D2C-BF3E-31F73FBF4E28@palisadesystems.com> <86zkcy5ur9.fsf@kopusha.home.net> <20120205093938.GC30033@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 5, 2012, at 3:39 AM, Pawel Jakub Dawidek wrote: > On Sat, Feb 04, 2012 at 08:16:42PM +0200, Mikolaj Golub wrote: >> ref8-amd64:/home/trociny% uname -r >> 8.2-STABLE >> ref8-amd64:/home/trociny% daemon -p /tmp/sleep.pid sleep 10 >> ref8-amd64:/home/trociny% daemon -p /tmp/sleep.pid sleep 10 >> daemon: process already running, pid: 19799 >>=20 >> kopusha:~% uname -r =20 >> 10.0-CURRENT >> kopusha:~% daemon -p /tmp/sleep.pid sleep 10 >> kopusha:~% daemon -p /tmp/sleep.pid sleep 10 >> kopusha:~%=20 >=20 > Mikolaj, eventhough what we had in 8.2-STABLE looks correct, it also > isn't correct. >=20 > Passing open descriptor to a process that doesn't expect that is bad > behaviour. If you pass, eg. open descriptor to a directory and the > process is using chroot(2) or jail(2) to sandbox itself it will be = able > to escape from that sandbox. Passing descriptor to a file has smaller > security implication, but it is still wrong. For example hastd, as you > probably know, asserts, before sandboxing, that he knows about all = open > descriptors - if there are some unknown descriptors open it won't run. >=20 > Also, daemon was passing open descriptor to a pidfile that the child > process cannot clean up, because he doesn't know its name. This leaves > pidfile with stale PID in it once the process exits, which is also = bad. >=20 > In my opinion, to make daemon(8) work with pidfiles, it cannot exit > after executing the given command. It should stay around with pidfile > open and just wait for the child to exit. Once the child exits, it > should remove the pidfile and also exit. If my understanding of flock(2) semantics is correct, with open(2) = O_CLOEXEC or fcntl(2) FD_CLOEXEC set on the pidfile, the closing of the = pidfile file descriptor during an exec will result in loss of the lock = on the pidfile regardless of whether daemon(8) hangs around to wait for = the child exit. Guy -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1E1FA19C-7C4C-4288-B163-E33FC68D9837>