It sounds like there was a genuine vulnerability that was fixed, so I'm reluctant to roll back the update in order to accommodate one customer.
Yesterday I signed up for a free Cushy account so I could reproduce and troubleshoot the problem. To my surprise ... no problem! Here's my best guess, I think the customer's web designer who set up the CMS probably used / as the path, while I used /web. And perhaps this was causing Cushy to explore directories not owned by the siteadmin, like maybe php.d. That still leaves the mystery of what changed in ProFTPd, because this was working since 2016. But I'm hoping the customer does not have the path set to /web, and that changing it will resolve the problem for her. (Note that I suspect the web designer has a branded pro account from Cushy and the customer is just enrolled as an editor of her site and therefore can't see or change the configuration.) Web designers can be difficult to deal with. They are artists! And hosting is just a commodity, low skill work by vendor scum who can be replaced with the snap of a finger. -----Original Message----- From: Blueonyx <blueonyx-boun...@mail.blueonyx.it> On Behalf Of Michael Stauber Sent: Thursday, August 1, 2019 1:09 PM To: blueonyx@mail.blueonyx.it Subject: [BlueOnyx:23063] Re: CushyCMS and ProFTPD Hi Ken, > Since the problem started with the ProFTPd bugfix, I'm starting to > wonder if CushyCMS uses the site cpfr and site cpto commands. That > seems unlikely, but I can't know for sure without signing up for a > CushyCMS account myself to try it. The only other explanation I can > think of is that the bugfix had some unanticipated consequences or collateral damage. Yeah, it sure is related to the update. The ProFTPd we're using now is a "release candidate" and I also observed that it does a few things slightly different than the last stable version that we were using. The code maturity seems to have dropped a notch or two. I don't have any other or better solution at the moment, sorry. But perhaps you might temporarily go back to the last ProFTPd version that worked for you? If so, please do this: rpm -e --nodeps proftpd rm /etc/proftpd.conf rm /etc/proftpds.conf That removes ProFTPd. Then you can grab the last good one. As I don't know which version of BlueOnyx you're using I'll be pointing you to the RPMs of the individual BlueOnyx versions: 5209R: http://updates.blueonyx.it/pub/BlueOnyx/5200R/el7/blueonyx/x86_64/RPMS/proft pd-1.3.5e-1BX7.x86_64.rpm 5208R: http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/x86_64/RPMS/proft pd-1.3.5-1BX5.x86_64.rpm 5207R: http://updates.blueonyx.it/pub/BlueOnyx/5200R/el6/blueonyx/i386/RPMS/proftpd -1.3.5-1BX5.i386.rpm Install the RPM of ProFTPd applicable to your BlueOnyx version this way: rpm -hUv <URL> Then restart CCEd and xinetd: /usr/sausalito/sbin/cced.init restart service xinetd restart To prevent YUM from updating ProFTPd again please edit /etc/yum.conf and find the lines that look like this: ## start-yum-gui exclude= ## stop-yum-gui Change it to this: ## start-yum-gui exclude=proftpd ## stop-yum-gui You actually can edit that via the GUI, too. It's under "Software Updates" / "YUM Updater" and in the "Settings" tab there is the form field "Exclude these RPMS". Instead of editing /etc/yum.conf you can directly write "proftpd" (without quotes) into that formfield to have it excluded from YUM Updates. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx