Re^2: Clues on writing a secure daemon

Yes, privileges: I want the file serving to be performed as the user who has logged in, by fork()ing and setresuid()ing. Unless I run apache as root and handle requests in CGI, it won't be able to do that.

My intention is to replace ftpd with a DAV equivalent. As far as I can see (and I've been researching this all day) I'm going to have to take the hit of having my master parent process run as root, but at least my children can be setuid'ed when they get round to actually doing anything.

This is not just another webapp. I must authenticate system users, because my objective is to give them access to their home directories. This is identical to the requirements of an FTP server. In fact, the only difference is the protocol used.

Comment on Re^2: Clues on writing a secure daemon

Replies are listed 'Best First'.
Re^3: Clues on writing a secure daemon by roju (Friar) on Oct 16, 2004 at 21:20 UTC
You don't need to run the listener as root. On startup, you open a pipe. You then fork. Process A drops privs to a junk user like nobody. Process B stays as root and blocks reading the pipe. Process A then listens on the network and performs any work, and then just passes a simple message onto B. B double-checks its input, and if it's good, forks a process as the requested user. The openssh have a good writeup, they call it Privilege Separation.	[reply]

Replies are listed 'Best First'.

Re^3: Clues on writing a secure daemon
by roju (Friar) on Oct 16, 2004 at 21:20 UTC

On startup, you open a pipe. You then fork. Process A drops privs to a junk user like nobody. Process B stays as root and blocks reading the pipe. Process A then listens on the network and performs any work, and then just passes a simple message onto B. B double-checks its input, and if it's good, forks a process as the requested user.

The openssh have a good writeup, they call it Privilege Separation.

[reply]