SOLVED SFTP - Incorrect upload permissions

[verdon]

When uploading new files and directories to the server, via SFTP logged in as a normal cpanel user, on a brand-new server 'CENTOS 6.8 x86_64 standard WHM 58.0 (build 23)' it seems that default permissions are wrong. The original files/dirs are all 644/755. When I upload with my GUI client (Transmit on Mac) the directories are being made group writeable but the files are ok (644/775), causing problems with suphp of course. Anecdotally, I believe I have a client using WS-FTP Pro on Windows, where files and dirs are being made group writeable (664/775). I need to verify that again.

I did some searching and had a look at /etc/bashrc and it looks correct. I sure haven't touched it.

# By default, we want umask to get set. This sets it for non-login shell.
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
umask 002
else
umask 022
fi


Any suggestion where else I might look?

 

[verdon]

Sorry, I was wrong about that... both clients are uploading files correctly but are both adding the g+w to directories.

 

[cPanelMichael]

Sorry, I was wrong about that... both clients are uploading files correctly but are both adding the g+w to directories.

Hello,

Could you verify if you were able to determine if the issue is isolated to specific SFTP clients? If so, does the issue persist when using an alternate SFTP client such as FileZilla?

Thank you.

 

[verdon]

Could you verify if you were able to determine if the issue is isolated to specific SFTP clients? If so, does the issue persist when using an alternate SFTP client such as FileZilla?

I can verify that it is happening with Transmit on MacOS (all up to date) and with up to date WS_FTP Pro on Win7, with using SFTP protocol. I'll try FileZilla on Mac shortly and see if I can get someone to try FileZilla on Win for me, and report back asap.

Thanks

 

[verdon]

I can verify that it is happening with Transmit on MacOS (all up to date) and with up to date WS_FTP Pro on Win7, with using SFTP protocol. I'll try FileZilla on Mac shortly and see if I can get someone to try FileZilla on Win for me, and report back asap.

It is happening with FileZilla on Mac also... I'm waiting for a Windows tester.

 

[cPanelMichael]

Hello,

It looks like this is a bug. Here's a quote from case EA-4868 regarding this issue:

By default, the umask is set to 002 for any user with a uid greater than 002. This causes issues for users who use the SuPHP handler and use SFTP to upload files/directories since the new files/directories will have 664/775 permissions by default

I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":

# By default, we want umask to get set. This sets it for login shell
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 022
else
    umask 022
fi

Thank you.

 

[verdon]

I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":

Thanks for this information. I've updated these values in /etc/profile and /etc/bashrc, restarted service sshd and started a new session in my sftp client, but am still getting 644/775 on files/dirs. Note that the files are correct. It's just the dirs.

Am I missing anything?
Thanks.

 

[verdon]

Note that the files are correct. It's just the dirs.

Oops. I'm still getting inconsistent results on this. I am getting 644/775 when I test. My client is getting 664/775.

 

[verdon]

Just a quick update... with the patch above, and after waiting a couple hours, upload permissions are correct with both Mac clients I can test with. I'm waiting for someone else to report on their Window's clients test.

 

[verdon]

Tested and verified with a couple Window's clients now, that the work-around is doing the job.

 

[cPanelMichael]

Tested and verified with a couple Window's clients now, that the work-around is doing the job.

I'm happy to see the workaround helped. I'll update this thread again when a resolution is published.

Thanks!

 

[borayeris]

It happens to me after I upgrade EasyApache4. It has been 3 months and still not fixed. Shame on you cPanel.

 

[cPanelMichael]

Hello,

There's no new update to report at this time, however this forum thread is linked to the case. I'll update this thread once the case is updated. In the meantime, let us know if you have any trouble with the recommended workaround.

Thank you.

 

[borayeris]

Hello,

It looks like this is a bug. Here's a quote from case EA-4868 regarding this issue:



I'll update this thread with more information on the status of this case as it becomes available. In the meantime, you can workaround this issue by changing the umask values in the following section of /etc/profile from "002" to "022":

# By default, we want umask to get set. This sets it for login shell
# Current threshold for system reserved uid/gids is 200
# You could check uidgid reservation validity in
# /usr/share/doc/setup-*/uidgid file
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
    umask 022
else
    umask 022
fi

Thank you.

This doesn't work. I did sshd restart. Also tried reboot.

 

[borayeris]

I found the solution.

In this file "/etc/ssh/sshd_config"

I find this particular line :

Subsystem sftp /usr/libexec/openssh/sftp-server

Changed to

Subsystem sftp /usr/libexec/openssh/sftp-server -u 022

After sshd restart it worked perfect.

 

[cPanelMichael]

Hello @borayeris,

I'm happy to see you were able to find a suitable workaround. Thank you for updating this thread with the solution you used.

 

[cPanelMichael]

Hello,

To update, in testing, we are finding the permissions of the files are matching the permissions assigned on the machine that's completing the upload via SFTP, which suggests it isn't an issue with the . EX:

1. Customer wants to copy 'hello.txt' to the cPanel server via SFTP.
2. hello.txt has permissions 0755 on the customer's machine.
3. After using sftp to copy the file to the cPanel server, the resulting file maintains 0755 permissions.

Could anyone experiencing this behavior confirm if it's happening when the permissions are not matching what's configured on the machine uploading the files, and if so, let us know the specific OS and SFTP client used for uploading?

Thank you.

 

[verdon]

I'm pretty sure I tested that when I made this initial post. I'd have to undo the patch suggested above, and run the tests again. If I get a chance in the next 24 hours I will... sadly, my snowblower will be taking all my attention tonight!

 

[cPanelMichael]

I'm pretty sure I tested that when I made this initial post. I'd have to undo the patch suggested above, and run the tests again. If I get a chance in the next 24 hours I will... sadly, my snowblower will be taking all my attention tonight!

We've completed some additional testing and have now reproduced the issue. No further information is required at this time, but thanks for monitoring the thread! I'll provide more information on the status of this case as it becomes available.

Thank you.

 

[cPanelMichael]

Hello,

To update, an EA4 maintenance update planned for tomorrow includes an update to the mod_suphp package that will address the issue reported on this thread:

mod_suphp
0.7.2-17 - EA-4868: Added new allow_file_group_writeable patch

You can review the full EasyApache 4 change log at:

EasyApache 4 Change Log - EasyApache 4 - cPanel Documentation

Thank you.