linux-kernel - RFC: implement daemon() in the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Nov 2006 14:20:52 +0100
From:	Simon Richter <Simon.Richter@...yros.de>
To:	linux-kernel@...r.kernel.org
Subject: RFC: implement daemon() in the kernel

[please CC me on replies]

Hi,

I'm working with Linux on MMUless systems, and one of the biggest issues
in porting software is the lack of working fork().

Except some special cases (like openssh's priviledge separation), fork()
is called in mainly three cases:

 - spawn off a new process, which calls exec() immediately

This can be easily replaced by a call to vfork(), which invokes the
clone() syscall with the CLONE_VFORK flag.

 - split off some work into a separate thread and provide address space
separation

Since we don't have a MMU, there is no address space separation anyway,
so we can replace this with a pthread_create(), which in turn calls clone().

 - daemonize a process

There is a function called daemon() that does this; its behaviour is
roughly defined by (modulo error handling)

int daemon(int nochdir, int noclose)
{
	if(!nochdir)
		chdir("/");

	if(!noclose)
	{
		int fd = open("/dev/null", O_RDWR);
		dup2(fd, 0);
		dup2(fd, 1);
		dup2(fd, 2);
		close(fd);
	}

	if(fork() > 0)
		_exit(0);
}

Since it calls _exit() right after fork() returns (so daemon() never
returns to the calling process except in case of an error) it would be
possible to implement this on MMUless machines if the last two lines
could happen in the kernel.

I can see three possible implementations:

 - "cheap" implementation

The process is assigned a new PID and the parent is pretended to have
exited. There are a lot of pitfalls here, so it is probably not a good idea.

 - a reverse vfork()

The child process is created and suspended, the parent continues to run
until it calls exec() or _exit(). The good thing here is that it should
be easy to implement as the infrastructure for suspending a process
until another exits already exists.

 - "normal" implementation

The child is created, the parent immediately zombiefied with a return
code of zero. This might be more difficult to implement as the current
implementation of fork() does not need to terminate a process in any
way, so there might be funny locking and other issues.

Questions? Comments?

   Simon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/