in reply to Re: Structuring a Web site and security issues
in thread Structuring a Web site and security issues

Thanks tirwhan.

First, I looked at suexec and decided I need to have a real pro set that up for me. Heady stuff indeed.

Secondly, could you recommend some books that you have found helpful. I did read CGI Programming with Perl, but doesn't go into the detail I'm needing right now.

Lastly, can you tell me where I can find out more about the piping scenario you mention? Sounds like it might be the ticket, but I'd like a bit moe of a nudge.

Thanks.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot
  • Comment on Re^2: Structuring a Web site and security issues

Replies are listed 'Best First'.
Re^3: Structuring a Web site and security issues
by tirwhan (Abbot) on Dec 26, 2005 at 19:10 UTC
    Heady stuff indeed

    :-) Yeah, suexec looks a bit intimidating. Once you get going it's not quite as bad as the docs make out though.

    It's not too easy to give book recommendations, because you haven't said what OS you're on, but these are some that I find very valuable on the subject:

    These cover different areas, all of them important.

    For the pipe, use the mkfifo command to create a pipe somewhere on your filesystem. Set permissions on the pipe to 0640, owned by your logging user (nobody) and a group that nobody does not belong to. You then need to start a process (as member of the reading group) that reads from the pipe and logs to a file which is inaccessible to nobody. I use socat for this but it's be easy to write something yourself.

    This way the nobody users can not see past logs (though he can sniff logs as they are written). The method has two drawbacks: 1.) The user can delete the pipe and create a file in its stead. If this happens at the same time as an apache restart, the server will then log to the file, which is readable by the user. 2.) If your second process (the one reading from the pipe) dies, the server cannot write and will fail.

    Another alternative is to write logs over the network, though this has its own problems and drawbacks.


    A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox