svn commit: r230869 - head/usr.sbin/daemon

[Guy Helmer]

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
>> 
>> kopusha:~% uname -r                         
>> 10.0-CURRENT
>> kopusha:~% daemon -p /tmp/sleep.pid sleep 10
>> kopusha:~% daemon -p /tmp/sleep.pid sleep 10
>> kopusha:~% 
> 
> Mikolaj, eventhough what we had in 8.2-STABLE looks correct, it also
> isn't correct.
> 
> 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.
> 
> 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.
> 
> 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.