[Bug 274813] www/elog: Revive port

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274813

Robert Clausecker <fuz@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open

--- Comment #5 from Robert Clausecker <fuz@FreeBSD.org> ---
Thank you for the update.  It seems to address my previous questions.

I have since found some time to review your patch:

 - in a recent change, the MANPREFIX variable has been eliminated.  Instead use
   ${PREFIX}/share/man (preferred) or ${PREFIX}/man
 - as your port is currently set up, the daemon configured by the rc.d/elog
file
   runs as root, not the elog user you added.  Is this intentional?  Try
setting 
   elog_user and elog_group in the script to run the daemon with the given
user.  
   It could also be that your daemon changes the user on its own, I didn't
check.
 - all the files in WWWDIR are owned by elog.  This means that if your daemon
   runs as that user, all these files are writable by the daemon.  This can be
   a security problem: if an attacker manages to compromise the elog daemon, he
   can persist himself by infecting these files.  Unless files need to be
written
   by the elog daemon, it is generally a good idea to give them to root:wheel
as
   usual.  Only give files and directories to elog:elog if they need to be
   written by the daemon.  It is usually best to lay out files such that paths
   with daemon-writable files and those without are clearly separated.
 - check if you can place the configuration file in ${PREFIX}/etc as is
   convention.   There can be exceptions, but it's usually better to have the
   configuration in the usual places.
 - your port installs a server key pair.  This is usually wrong: each
   installation needs its own key pair, so the pair can't be shipped in
   the binary package.  Many daemons can be configured to generate a key pair
   on first start if none exists.  Check if that would do the trick.
   Alternatively, add a post-install script or some magic to the rc.d script to
   generate the key pair after installation.

-- 
You are receiving this mail because:
You are the assignee for the bug.