From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
when the rpm update is installed, the default action is to rename 
the /etc/ftpusers file and replace it with rpm version.  If anon ftp has 
previously been disabled by adding ftp user to ftpusers (a common 
practice) then installing the update opens up the server to anon ftp 
access, a weak security profile.  Additionally, if users are prevented 
from using ftp by listing in /etc/ftpusers (a common practice), then 
installing the rpm instantly grants them all ftp access.  If ftp service 
has been disabled (via chkconfig --level 2345 wu-ftpd off), then 
installing the update rpm overrides this configuration and enables ftp.
Installing this rpm has significant consequences for a properly configured 
and secured server.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. disable ftp with chkconfig
2. add ftp and other login names to /etc/ftpusers
3. install update rpm
	

Actual Results:  FTP service is enabled.  Anonymous FTP is enabled, and 
any user logins previously denied ftp access are now granted access. Ouch!

Expected Results:  /etc/ftpusers.rpmnew should have been created instead 
of /etc/ftpusers.rpmsave.  /etc/xinetd.d/wu-ftpd should not be overwritten 
if no changes are mandated, and should be handled properly if service was 
previously disabled.

Additional info:

rpm used:

wu-ftpd-2.6.1-16.7x.1.i386.rpm

I am 99% sure about the "chkconfig" part of the report, but I don't have a 
fresh example in front of me to confirm it absolutely.

Users of up2date (or autorpm) would be unaware that the security profile 
of their box was changed overnight, without warning, and if a new local 
ftp exploit is discovered against the release, the user is setup for being 
rooted..