> Am 20.06.2017 um 17:43 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > On Tue, Jun 20, 2017 at 6:39 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: >> >>> Am 12.06.2017 um 21:35 schrieb Ruediger Pluem <rpl...@apache.org>: >>> >>>> 2. Persist responses (is this just a config/default issue?) >>> >>> This could become tricky given the various so cache implementations we >>> have. I could >>> only think of persisting the whole cache when Apache is shutdown. >> >> I am not very experienced with those. Would the current Stapling >> implementation not work with a "socache_dbm"? And what would be the drawback >> of that? >> >> As an alternative, use of mod_watchdog offers advantages here. If we have >> only one thread (for all or for a particular certificate) that writes the >> cache in a server (all processes), it becomes easy to use the file system, I >> think. Write per tmpfile+rename should be good enough and it should no >> longer need a global mutex. Server names are distinct and make for an easy >> directory tree. >> >> The question then is if mod_watchdog jobs still have privileges or if those >> files have common ownership and if that is a problem. >> >> Does this makes sense or am I insane? > > I consider it very unwise to use root to perform client queries, almost > as unwise as serving any responses. The problem in both cases is > that every defect in parsing (and there is 'input' in either case) opens > up the remote possibility of a root exploit. > > All client requests, for stapling, for health check, for any purposes > whatsoever should be performed as httpd configured user. Whether > that happens in an ombudsman resource process or the typical > worker process is a design question. > > Yes, a dbm certainly should survive a server restart, that's why one > would use dbm for the SSL Session Cache (before session tickets > offered a fresh solution - although these suffer just as many issues > as our OCSP implementation so far.)
I share your point of view. I do not want to make OCSP requests as root. As far as I can tell, that would mean the dbm file is owned by the configured user. My question is: is this acceptable or do we have an alternative?
