On Sun, 22 Sep 2002, Joshua Slive wrote: > Rich Bowen wrote: > > > OK, I'm confused. What here would you have to do as root that should not > > be that way? > > I'm not anything near a security expert, but ... > > Your permissions keep ordinary users entirely out of the Apache > directories. This prevents ordinary users from doing, among other things: > > - Running log-analysis programs > - Reading the error log > - Running htpasswd/htdigest/ab and other support programs > - Reading the httpd.conf to check how the server is configured
Yes, that was the goal. > Now, it could be argued that under some circumstances, an adminstrator > would not want ordinary users to do those things. For example, the > error log could contain sensitive error dumps from cgi scripts. Or the > httpd.conf could contain database passwords for php scripts. But in > general, a properly configured system should not really need to restrict > these things. The idea was to lock things down as tightly as possible, and then use that as a baseline for relaxing things based on needs that arose. Keep in mind that the folks in question were security experts, whose entire job is to be paranoid. > The philosophy of the existing recommendations is to restrict write > access tightly, but to allow pretty-much unlimited read access. I don't > see this as a bad idea. Perhaps the docs should note that more > restrictive read-permissions are possible, but I don't think they need > to be "recommended". Granted. The phrasing could be be better than what I have suggested. > As far as the log directory, you've already discovered that it works in > general with the recommended no-write-permissions-to-non-root. I > believe there may be some things (like the scriptlog) that don't work > that way. For these logs, it is necessary to create the file in advance > and chown it to www. > > Regarding the requirement for mod_mime, I do belive that is some kind of > a bug. I recall some discussion of this a long time ago on new-httpd, > but I can't remember the conclusions. I'd guess the only way to figure > it out would be to walk it with a debugger. I'll paw through the archives and see what I can come up with. > So, in conclusion, I like the idea of adding a discussion of how to > remove features (modules) that aren't needed, and perhaps a little bit > more discussion of file-permissions. But I don't really see any need to > change the recommended file-permissions. If that is the consensus, I'll drop it. I think that the document could stand to be expanded in a number of areas, and that a broader discussion of file permissions would be good here. I think that I agree re actually recommending that everyone change their file permissions, in general. Perhaps merely discussing them more will get people thinking in areas that they would not otherwise. Re modules, I find a huge number of people on IRC that have modules installed that they don't even know what they do, let alone actually need them. I had thought before of what would be the minimal module load, but had never actually attempted to do one. I found it an interesting and informative experiment. I also discovered the --enable-module=none flag, which is not documented anywhere that I could find. -- Who can say where the road goes Where the day flows Only time --Pilgrim (Enya - A Day Without Rain) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
