> >perhaps you should stat the file and make sure its a normal file? >There may be other device files which cause problems by virtue >of having lots of data, or by blocking for long periods of time. >For example a blocking read on a dialup device that waits for >carrier sense on a modem. Is there any reason to allow device >files to be read from the config? Open the file non blocking and then fstat() it will do away with the race condition. (Some devices block on open, like dial-in ports) >This may not stop all possible attacks. Normal files might be >used to indefinitely block the daemon. For example some systems >allow regular users to make NFS mounts. In this case an NFS >server can be brought up, mounted, then brought down. The >httpd reading an nfs mounted file would then block for a long >period of time while NFS times out. The same result can be >achieved by performing a denial of service attack against an already >existing NFS mount. Or if you use a default /net automount on Solaris, just open "/net/far-a-field" Seems like a problem that's hard to generally fix, other than making sure noone gets to write .htaccess files. >Are there other ways to cause long blocking times when reading >normal files? Do any common unix systems have mandatory file locking? Yep, that's a way too; most SVR4 derived systems have it, I think. Solaris certainly has it. Casper
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:39:37 PDT