update 1.35.0 has created a sea of mess/confusion across most of my servers

[gadgetsguy]

ok ....

as I am rolling out update 1.35.0 across my 37 servers, most of them are giving me error messages about something needs my attention ...

It seems that all apache owned files are now preventing proper backups from running.

Now they say the solution is to go and change the ownership on each individual file, or if you absolutely cannot change ownership, consult another post for code to run an alternate backup ...

This just F's me right up!! - (pardone mon français) I have probably 1000+ files and folders affected by this, and some of them I don't even know the script the client is running - to to know whether changing the ownership is going to cause a major sh!tstorm or not ...

There has got to be a better way of going about this, for us owners who have multiple servers affected by this update?

PLEASE HELP!!

 

[floyd]

I also agree that the cure for the security risk is more harmful than the security risk itself.

 

[RHS-Chris]

Just thought I would post my comments. A server that does not run suphp/SuExec, could possibly have many files that are owned by the apache user, as this would be the user responsible when someone uploads through a web page. I have two suggestions regarding how to help fix this issue for frustrated server admins. First, as part of the backup process, change the ownership of apache owned files to the proper user, automatically. Second suggestion, put it back to the way it was.

Is there any more information available on this bug fix besides this page:

http://www.directadmin.com/features.php?id=1052

 

[DirectAdmin Support]

Hello,

We're trying to come up with the best solution possible, while not sacrificing security at the same time.

The only solution (going back to the previous method aside) that I can see at this time is to run tar with process access:

user:apache

With apache as the group, that should be able to see all the files (unless I'm missing something). It's not as secure as user:user, but this current solution obviously isn't working.

If we go this route with user:apache as the tar process, I'll also include an option in the directadmin.conf to shut it off, and force user:user.

Having DA cycle through all files and resetting them is out of the scope of DA's role. If needed, I can code it, but isn't a very clean solution, as I can see it causing issues like breaking setups, etc..

Comments welcome, but we'll continue this thread here, relating to the actual issue:
http://directadmin.com/forum/showthread.php?t=34892&page=2

John