On Fri, Aug 29, 2008 at 07:45:12AM -0400, Eric Covener wrote: > On Fri, Aug 29, 2008 at 2:05 AM, Joseph S D Yao <jsdy@xxxxxxx> wrote: > > > Even if 'httpd' is still running as root when reading the cert, and so > > able to use it, it is still a bad idea to have it OWNED by root - you > > still have to have super-user powers to maintain it. Bad, bad, bad, > > bad, bad. > > You should need superuser access to read, much less modify, a > [unencrypted] private key used by Apache. Concur. > > and so the uncloaked cert files should be stored as > > read-only by "apache". You DO know that the owner of a file *always* has control of its access mask? and thus cannot be denied write if he really wants it? > This is criminally negligent advice, as the userid used for > request-processing shouldn't be able to read this confidential data. Don't confuse certificate and private key. The cert. can be 644 since it contains only the PUBLIC key. Indeed, the cert. can be served up to the world from a public page without harm -- we're all *supposed* to be able to get it. The private key, OTOH, should be locked up tightly. I see no reason not to use root for that. What does it buy you to have *two* must-protect-at-all-costs accounts (unless the holders are disjoint and distrust one another)? Apache HTTPD and a number of other daemons are carefully constructed for exactly this usage: start as root, acquire all privileged resources, switch to unprivileged UID. See for example jsvc that comes with Apache Tomcat, or UDel ntpd, or.... -- Mark H. Wood, Lead System Programmer mwood@xxxxxxxxx Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
Attachment:
pgprEBybzFek5.pgp
Description: PGP signature
|