Users home directory permissions changed

[4u123]

I've had an ongoing issue with an account, whereby without warning,randomly the home directory permissions change from 711 to 750 and the group changes to nobody.

The first thing the user notices is that he stops receiving Email. Exim fails to deliver with the error Permission denied: failed to chdir to /home/username

This doesn't happen for any other user and this is the only account I've ever seen with this problem. It's been going on for a couple of years. When it happens, the user contacts me and I reset the permissions. He can be fine for six months before it happens again, or it could happen three times in a week. Seemingly it's random.

I'm puzzled. Any advice appreciated.

 

[HostingH]

Hello,

Seems security issue, please check root or user's bash history, and cpanel/secure logs to get more information about it.

 

[4u123]

Yeah I've done all of that. There's nothing out of the ordinary. This user has a number of PHP scripts that he has developed himself, so it has always been my impression that there is a vulnerability in one of them - however, if that was the case, there would be some malicous activity -and there isn't, only the permissions change. We've also found a number of sub directories in his account with the same permissions change, but not all of them. Seems only to be directories, with the files unchanged.

 

[cPanelMichael]

Hello,

Feel free to open a support ticket using the link in my signature if you'd like us to take a closer look to see what could be altering the permission and ownership values.

Thank you.

 

[4u123]

I put an audit watch on his home directory.

The client contacted me 20 minutes ago to say that overnight the file permissions changed again. I checked the audit log which told me there were two executables that ran against his homedir...

updatedb - can't be that.
enablefileprotect - bingo!

It must be fileprotect - considering that script is tasked with changing file permissions. Not sure why it would change the perms on his homedir instead of simply changing his public_html and addon directories.

I'm making a guess that the script will determine the docroot for hosted domains and set the permissions on that directory accordingly. So - if for some reason the docroot of a domain is set in a config file somewhere to /home/username rather than /home/username/public_html - it stands to reason that the script might make those changes - although it is unclear why the permissions would not be changed for several days then suddenly changed.

I think it is possible that the fileprotect is being triggered by a hook and it is only being run after a certain event.

Am I correct in thinking that now we are using EA4, the fileprotect script is no longer running every day?

My next question is, how is the script determining what directories need changing? Apart from httpd.conf, I'm guessing there are other files that contain the paths for the domains on the server.

This particular user account was set up in 2006, so it's very possible that there are some discrepancies that could be easily fixed.

I'd appreciate any assistance in determining how the enablefileprotect script locates the directory info it needs to change permissions. I've looked at the script but I'm not a programmer and I wasn't able to work it out.

 

[cPanelMichael]

Hello,

For anyone else browsing this thread with the same question, note the referenced option is "Enable File Protect" and is found under the "Security" tab in "WHM >> Tweak Settings". The File Protect functionality will check the permissions and ownership values on each user account's home and public_html directories and each addon domain's DocumentRoot directory and then set the values accordingly.

It's by design that the /home/$username directory permissions are modified if they are not setup correctly when file protect is enabled. It runs automatically anytime an Apache RPM is updated (which can happen automatically if you have automatic updates enabled). You can view this file directly to get a better idea of how it works on the backend:

cat /scripts/enablefileprotect

For example, here's the corresponding section related to the home directory permissions:

print 'Setting permissions for.....';
while ( my @PW = getpwent() ) {
    next if ( !$PW[0] || !-e '/var/cpanel/users/' . $PW[0] );
    my $useruid = $PW[2];
    my $usergid = $PW[3];
    next if ( $useruid < Cpanel::LoginDefs::get_uid_min() );
    my $homedir = $PW[7];
    next if !$homedir || !-d $homedir;

    print "$PW[0] …\n";

    try {
        warn $_->to_string() for Cpanel::FileProtect::Sync::sync_user_homedir( $PW[0] );
    }
    catch {
        print "Skipping $PW[0] because of an error: $_\n";
    };
}
endpwent();
print "...Done\n";

Thank you.

 

[4u123]

Hello,

For anyone else browsing this thread with the same question, note the referenced option is "Enable File Protect" and is found under the "Security" tab in "WHM >> Tweak Settings". The File Protect functionality will check the permissions and ownership values on each user account's home and public_html directories and each addon domain's DocumentRoot directory and then set the values accordingly.

It's by design that the /home/$username directory permissions are modified if they are not setup correctly when file protect is enabled. It runs automatically anytime an Apache RPM is updated (which can happen automatically if you have automatic updates enabled). You can view this file directly to get a better idea of how it works on the backend:

cat /scripts/enablefileprotect

For example, here's the corresponding section related to the home directory permissions:

print 'Setting permissions for.....';
while ( my @PW = getpwent() ) {
    next if ( !$PW[0] || !-e '/var/cpanel/users/' . $PW[0] );
    my $useruid = $PW[2];
    my $usergid = $PW[3];
    next if ( $useruid < Cpanel::LoginDefs::get_uid_min() );
    my $homedir = $PW[7];
    next if !$homedir || !-d $homedir;

    print "$PW[0] …\n";

    try {
        warn $_->to_string() for Cpanel::FileProtect::Sync::sync_user_homedir( $PW[0] );
    }
    catch {
        print "Skipping $PW[0] because of an error: $_\n";
    };
}
endpwent();
print "...Done\n";

Thank you.

Thanks for the explanation of what fileprotect does. Unfortunately it doesn't explain why it is changing the file permissions incorrectly on this user's home directory.

When this problem happens, we reset the permissions and ownership to the correct ones. Then fileprotect changes the home directory to be owned by nobody with 0750 permissions as if it was a public_html or addon directory. So for this one user, for some reason fileprotect seems to determine that his correct permissions are not so.

In my opinion, because the script is changing his permissions to that of public_html or an addon directory, it must somehow consider his home directory to be an addon directory. I'd like to know whether this is possible and how?

EDIT: I just checked his addon, alias and sub domains...

He has a subdomain with the docroot set to / (i.e /home/username). It looks like fileprotect is picking up on this and subsequently setting the permissions accordingly.

I don't think it is possible to set the docroot on a sub, parked or addon to the home directory these days, but as this account is 11 years old, I'm guessing it was at one point allowed.

I'm pretty sure removing that sub domain will resolve the problem. I'll update this thread with results.

 

[rpvw]

Have you tried switching the fileprotect off for a few days, to ensure it is indeed that which is changing the permissions ?

It would be irritating to have to go through a whole lot of debugging of fileprotect to only find out that something else was responsible

 

[4u123]

Have you tried switching the fileprotect off for a few days, to ensure it is indeed that which is changing the permissions ?

It would be irritating to have to go through a whole lot of debugging of fileprotect to only find out that something else was responsible

I don't need to do that. I discovered that fileprotect was indeed changing the permissions. Quote from my previous post...

I put an audit watch on his home directory.

The client contacted me 20 minutes ago to say that overnight the file permissions changed again. I checked the audit log which told me there were two executables that ran against his homedir...

updatedb - can't be that.
enablefileprotect - bingo!

 

[4u123]

While this is a legacy issue and likely only to have a small number of cases, I think it would be wise for cpanel to update their fileprotect script to skip changing the homedir permissions if a parked, addon or sub domain has it set as the docroot - or at least switch the functions around so that the homedir check comes after the other checks, so that if the script changes a homedir to nobody and 0750, it will get changed back again anyway.

 

[cPanelMichael]

Hello,

To update, internal case CPANEL-14184 is open to address an issue where it's currently permitted to use the user's home directory as the document root for addon or subdomains. We recommend not configuring the home directory itself as the document root, as this can lead to the exposure of system files (e.g. .my.cnf, email), and also has the side effect of breaking permissions if fileprotect is enabled. I'll monitor this case and update this thread with the outcome once it's complete.

Thank you.

Update: CPANEL-14184 is scheduled for inclusion with cPanel version 72 and will ensure that attempts to use "/" and system directories for document roots are rejected.

 

[AzeDK]

EDIT: I just checked his addon, alias and sub domains...

He has a subdomain with the docroot set to / (i.e /home/username). It looks like fileprotect is picking up on this and subsequently setting the permissions accordingly.

I don't think it is possible to set the docroot on a sub, parked or addon to the home directory these days, but as this account is 11 years old, I'm guessing it was at one point allowed.

I'm pretty sure removing that sub domain will resolve the problem. I'll update this thread with results.

Thank you! This solved a 2 year long headache for us.

 

[cPanelMichael]

Hello,

As of cPanel & WHM version 70, we now reject attempts to use "/" and system directories as the document root for addon or subdomains:

Fixed case CPANEL-14184: Reject "/" and system directories for document root.

This should help prevent cases where permissions are set incorrectly when the file protect feature is enabled.

Thank you.

 

[mehdix92]

I would like to re-open this thread as I occurred for one of our clients repeatedly on the current Cpanel Versions.

I ended up removing the Subdomain with rootdir to / to fix the issue but similar cases might happen again.

Please advise.

 

[cPanelMichael]

Hello @mehdix92,

Internal case CPANEL-14184 only apples to the creation of new addon domains or subdomains. You'll need to modify the document roots of existing addon domains or subdomains if they are set to the account's home directory.

Thank you.