Preserve apache file permissions

floyd

Verified User
Joined
Mar 29, 2005
Messages
6,159
Backing up and transferring to a new server is a real pain when some files were created by php scripts and therefore owned by apache. The restore function changes the file ownership of the apache owned files back to the user and thereby breaking some php scripts that need write privileges.
 
My personal opinion is that running php scripts as apache is outdated and insecure. Am I wrong?

Jeff
 
My personal opinion is that running php scripts as apache is outdated and insecure. Am I wrong?

That may be but I am a little nervous about changing to suphp on production servers. I don't see how it is insecure as the user apache has less privileges that the regular user. But where it is secure or not, or outdated or not, is not the point.

I just started testing a machine to see if I can do a customapache install and then change to custombuild and also make the httpd.conf file include all the other files custombuild generates. I hate having to have all the other files for apache. I am used to having everything in one file except for the user httpd.conf files

If I can do what I want I will then generate a list for myself of stuff that has to be done similar to what I use now for new installs.

I may even acquiesce to having multiple config files if I can get used to it. I am kinda old and set in my ways.

However all that being said I still have a bunch of servers running php as apache and any time I move an account it spells trouble for accounts that need apache to write to files.

DA staff recognizes that people still run php as apache and therefore changed the file manager to reset apache owned files. Also a php patch was provided so that the user and script name could be included in php sent mail header running as apache. I am asking for something similar in that I want the apache owned file to stay owned by apache during a server move.

To accomplish what I want now:

1. Suspend the account
2. Rename the domains directory to something else so the backup system does not waste time tar'ing something I cannot use. Perhaps domains.old
3. Run the backup
4. tar the domains.old directory preserving permissions.
5. Transfer the DA backup file and the tar file of the domains.old directory.
6. Run the restore
7. Untar the domains.old file
8. Rename domains.old to domains.

I guess the problem is that the uid of apache on one server might now be the uid of apache on another.

However the restore process could check to see what the uid is in the backup and match that against the uid of the new server.
 
You make some good points. I agree with you that I'd rather have a monolithic httpd.conf file, but it may be easier for DirectAdmin to administrate the multiple files.

Of course if you're old enough you remember when apache used multiple config files; I don't remember at what version number but I do remember when the apache group said that separate files were no longer required; that apache would look for all configuration files but wouldn't care what was in which file.

That was quite a while ago.

Jeff
 
I started with the last version of RedHat 5.x I don't remember what the x was. I remember 6.0 came out a few months after I started.

But what I remember was that apache (1 something) used one file by default at that time and then I switched to using mandrake some time later which used apache 2 and separate files by default. Every time I did an install I would combine all the files into one.

I hate changing just for the sake of change. It seems like if I want to be able to use suphp easily then I have to make a bunch of other changes.
 
Hello,

Although I'm always hesitant to use root to let a user break out of his own user to some other user (eg apache) it would probably save a lot of time, assuming it's all done right. One thing to note is that DA doesn't actively change apache owned files to the user during a restore, what's happening is the user is extracting his own tar.gz for security reasons, thus the files end up being owned by him. In any case, the simple solution is to have a simple text file listing all files owned by apache. Thow it into the tar.gz. After extraction, read in that list and chown everything back to how it was.

I mentioned above that it's important to do it right. The potential hazards of using root to give a user something he didn't have before are things like hard links. If a user links to other files and you restore his account and DA finds that same file in it's apache owned list, then root has just changed ownerships of some file on your system to apache. Of course, because I'm aware of these types of tricks, I'll take note to check for them.. however you still can't beat relying on unix security. User bob extracts a file, files are owned by bob. Simple, you can't screw that up. Once you get root involved changing things after the fact, you have a higher risk of error beause you're taking matters into your own hands, and also adding complexity.

ANYway, bit of a ramble, but I can add this to the versions system and look into doing it correctly, securily and as simply as I can ;)
http://www.directadmin.com/features.php?id=956


In any case:
1) suPhp is good, and solves a lot of these issues, but is a slight performance hit.
2) if you want to use apache user, this is a good guide:
http://help.directadmin.com/item.php?id=254
and also still applies for suPhp as well.

And this is just a general list of good security tips, if you've not already seen them:
http://help.directadmin.com/item.php?id=247

John
 
But what I remember was that apache (1 something) used one file by default at that time and then I switched to using mandrake some time later which used apache 2 and separate files by default. Every time I did an install I would combine all the files into one.
Configuring apache was always left up to the various distributions. At that time Red Hat ha already switched to one monolithic file, while Mandrake was still using the original cnfiguration.

Here's what my copy of Linux Apache Web Server Administration, published by Sybex in 2001, says on the subject:
In keeping with its NCSA httpd origin, Apache originally used three configuration files:
The main server configuration file, httpd.conf
The resource configuration file, srm.conf
The access permissions configuration file, access.conf

The Apache Software Foundation decided to merge these into a single file, and in all current releases of Apache, the only configuration file required is httpd.conf.

It's a good book; I still use it as my major reference for the httpd version 1.x tree.

Jeff
 
It's a real problem, that backup do not preserve apache owned files.

A lot of programs works with such of files. I am moving 75 users to a new server, and I just discover that...

=> list of all apache files :
Code:
find /home -group apache > /root/filesapache.txt

But after, how to give back files to apache ?
chown apache:apache file1 file2 file3 ... but it is a little long

Have you another solutions ?

I know I can also do with rsync.
But => do a backup to have all configs, then do rsync, it's a little strange :D
 
We are using mod_ruid on all our systems, and don't have any problems.
If we backup a user, and restoring it on another server everything works directly, without changing manually the permission/ownership.
 
We are using mod_ruid on all our systems, and don't have any problems.
So ruid does the same thing as suphp I gather?

I'd love to switch to suphp, but as floyd said, I'm nervous of changing too (files owned by apache will be unreadable, chmodded files, etc). Does ruid treat this situation the same or better than suphp?
 
=> list of all apache files :
Code:
find /home -group apache > /root/filesapache.txt

But after, how to give back files to apache ?
chown apache:apache file1 file2 file3 ... but it is a little long

Have you another solutions ?

If you are going to be a server admin you really need to learn to do some of these simple things. Any job that is repetitive can be scripted.

Code:
# Perl code

@list = `cat /root/filesapache.txt`;
chomp(@list);

foreach $list(@list){

        `chown apache:apache $list`;        

}
 
Yes Floyd, you are right ! I have to learn, and each day, I learn new things.
Thanks for your reply.

Regards
 
So ruid does the same thing as suphp I gather?

I'd love to switch to suphp, but as floyd said, I'm nervous of changing too (files owned by apache will be unreadable, chmodded files, etc). Does ruid treat this situation the same or better than suphp?
The files created via PHP script or something (HTTP) will be owned by the user itself, and not 'apache'.

We are using mod_ruid since the beginning of our company, so we don't have the problem with "file XXX must be chmod 666/777" etc.

To install mod_ruid do the follow;
wget http://downloads.sourceforge.net/pr...cts/mod-ruid/files/&ts=1282306845&mirror=kent
tar xjf mod_ruid2-0.9.tar.bz2
cd mod_ruid2-0.9
apxs -a -i -l cap -c mod_ruid2.c
Now mod_ruid2 should be installed and activated in httpd.conf

For the last steps you can follow my post HERE.

From now if you create a file with apache, the file is owned by the user self and not 'apache'. So you also don't need to chmod things.

Also when there is a bug in the site, and with that bug they can run a perl script, the perl script will be started by the user, and not from apache.
 
From now if you create a file with apache, the file is owned by the user self and not 'apache'. So you also don't need to chmod things.

How does this affect a server already in production? Do we need to chown the previously owned apache files to the user?
 
daveyw, your suggestion is very interesting.

=> so, same question, what about server already in production ? Consequence for actual users ?

You give us your hand to help us, now we ask your arm :rolleyes:


PHP is always working as CLI and not CGI ?
 
How does this affect a server already in production? Do we need to chown the previously owned apache files to the user?
This can be easy tested with the follow steps, since i'm not sure if this affect it.

- Install mod_ruid2 (this will not affect anything!)
- Go to 1 user with files owned by 'apache', edit the httpd.conf of that user and add the follow things
Replace the 'SuexecUserGroup' line with

RMode config
RUidGid admin admin
RGroups apache
** change 'admin' to the username of the user.
For safety it won't be overwritten do
chattr +i httpd.conf
Now reload HTTP and try it out, if it does affect you can do;

- chattr -i httpd.conf
- remove the RMode, RUidGid and RGroups from the httpd
- add the 'SuexecUserGroup' again
- reload HTTP

If its affecting: The files need to be chown'ed from 'apache' to the user.
If its not affecting: Good, now you can follow the steps in the other topic to get this enabled for all domains/users on the server.

PHP is always working as CLI and not CGI ?
It depends on the option you chosed when install DA. We install DA always with PHP-CLI and not CGI.
 
Last edited:
Yes, I work with CLI, so I want to stay with CLI.

Thanks for previous explanations to test.

3 other questions :
=> I suppose it does not affect wildcard sub-domains while changing httpd conf ?
=> about a script like softaculous, writing "good" permissions (I mean chmod 777 to needed directories) : does softaculous understand new option, and keep "normal" chmod ?
=> about directories : no more 777, they all can stay at 755 ? that's what I understand with your explanations.
 
=> I suppose it does not affect wildcard sub-domains while changing httpd conf ?
No, but for the test 'steps' the httpd.conf file will be readonly. So the file can't be changed. To make it writeable again you need to use the 'chattr -i' command as writed.
=> about a script like softaculous, writing "good" permissions (I mean chmod 777 to needed directories) : does softaculous understand new option, and keep "normal" chmod ?
We have Softaculous also and tried some scripts and we didn't make any changes with the file permissions. So yes, it should work also correctly with Softaculous.
=> about directories : no more 777, they all can stay at 755 ? that's what I understand with your explanations.
Yes, since the file is owned by the user, and you are working under the user. Because without mod_ruid you are working under the user 'apache', the files are owned by 'user'. So then you need to change the permission/ownership because it is not writeable for apache.
 
Re-asking the same question user Peter Laws asks in post 11 of this thread:

What if any are the practical differences between running under suPHP and mod_ruid?

Jeff
 
Back
Top