Cpanel Easyapache Symlink w/dso vs suPHP

[misterlugal]

On the cpanel boxes so far I have been switching to suPHP before applying the easyapache patch.

I'm running into a lot of headaches with old sites. Is is possible to apply the patch and keep on dso or keep on dso with one of the other solutions?

 

[quizknows]

You can use the rack911 patch and still use DSO.

Honestly most of your problems are probably due to SuPHP not wanting world write on files/directories. If you run these shell commands on the affected username it will probably make it work fine with SuPHP:

find /home/username/public_html/ -type f -exec chmod 644 {} \;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -exec chown username:username {} \;
chmod 750 /home/username/public_html/
chown username:nobody /home/username/public_html/

This will set proper permissions and ownership on everything under the 'username' account for use with SuPHP.

Regardless, I still recommend the rack911 patch instead of the one cPanel put into EA.

 

[cPanelKenneth]

You can use the rack911 patch and still use DSO.

Honestly most of your problems are probably due to SuPHP not wanting world write on files/directories. If you run these shell commands on the affected username it will probably make it work fine with SuPHP:

find /home/username/public_html/ -type f -exec chmod 644 {} \;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -exec chown username:username {} \;
chmod 750 /home/username/public_html/
chown username:nobody /home/username/public_html/

This will set proper permissions and ownership on everything under the 'username' account for use with SuPHP.

Regardless, I still recommend the rack911 patch instead of the one cPanel put into EA.

You should filter out files owned by root (and probably other system users) prior to executing the above chown or chmod commands. Otherwise you can give malicious users access to things they shouldn't.

Example, given malicious user 'baddie'. He can:

$ ln /etc/shadow ~/public_html/myconf.txt

Once your chown or chmod commands run, baddie now has access to your password hashes.

 

[quizknows]

Good point. Using type f and type d with the chown command would avoid changing ownership of anything that a symbolic link is pointing at.

find /home/username/public_html/ -type f -exec chmod 644 {} \;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chown username:username {} \;
find /home/username/public_html/ -type d -exec chown username:username {} \;
chmod 750 /home/username/public_html/
chown username:nobody /home/username/public_html/

 

[cPanelKenneth]

Good point. Using type f and type d with the chown command would avoid changing ownership of anything that a symbolic link is pointing at.

find /home/username/public_html/ -type f -exec chmod 644 {} \;
find /home/username/public_html/ -type d -exec chmod 755 {} \;
find /home/username/public_html/ -type f -exec chown username:username {} \;
find /home/username/public_html/ -type d -exec chown username:username {} \;
chmod 750 /home/username/public_html/
chown username:nobody /home/username/public_html/

That doesn't protect against hardlinks, which is what my example uses.

 

[quizknows]

Point taken.

My instructions weren't meant to be an end all, rather an explanation that typically when you switch from DSO to SuPHP, you need to fix permissions/ownership on the sites files.

 

[cPanelKenneth]

Point taken.

My instructions weren't meant to be an end all, rather an explanation that typically when you switch from DSO to SuPHP, you need to fix permissions/ownership on the sites files.

That is an important point. A wide range of problems can occur due to the ownership and permission problems.

My post is simply meant to be cautionary and informative.

 

[nospa]

hard links only exist if your /home directory is on the same partition as other directories , eg. in most cases it is on VPS servers. You should always put /home on separate partition, so flags like -type f or -type d will protect you agains changing anything else than files and dirs.

 

[cPanelKenneth]

hard links only exist if your /home directory is on the same partition as other directories , eg. in most cases it is on VPS servers. You should always put /home on separate partition, so flags like -type f or -type d will protect you agains changing anything else than files and dirs.

+1 to putting /home on its own partition.

Since regular files are themselves hardlinks the f and d flags will not protect in this situation. Regular (meaning non-privileged) users can create a hard link (and a symlink) to any file that exists on the same partition. If the original file has different ownership, that will be reflected in the resulting, newly created hardlink.

As a regular user, in my home directory I can:

1. Create a symbolic link to any file on the system I can reach
2. Create a hard link to any file on the partition I can reach
3. Delete any file in a directory I control
4. Rename any directory in a directory I control

(Points 3 and 4 are meant to counter the notion that root-owned files and directories in a user's home directory are somehow safe from manipulation by the user)

Remember that in the non-malicious user case (which is hopefully the common case for everyone) file ownership mismatch is not much of an issue. It just takes one malicious user to ruin your day (week, month, year).