Re: Clues on writing a secure daemon

Two bits of advice:

Never use the system's users to authenticate web apps. That's a high security risk and even if everything is encrypted via SSL you're still open to careless users writing their passwords in insecure places. And a persistent hacker could use the web interface to guess user passwords (90%+ of user-picked passwords are trivial) and then attack your system.
Any good reason not to use apache? Apache will do all the serving for you and, through mod_perl, you can still program everything you need in Perl. I never tried mod_perl and DAV integration but Apache::DAV seems to be worth trying at least.

ESC[78;89;13p ESC[110;121;13p

Comment on Re: Clues on writing a secure daemon

Replies are listed 'Best First'.
Re^2: Clues on writing a secure daemon by n3dst4 (Scribe) on Oct 16, 2004 at 14:55 UTC
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.	[reply]
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]