SOLVED SFTP - Incorrect upload permissions

verdon

Well-Known Member
Nov 1, 2003
923
11
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
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?
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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

Well-Known Member
Nov 1, 2003
923
11
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
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

Well-Known Member
Nov 1, 2003
923
11
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
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

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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":

Code:
# 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

Well-Known Member
Nov 1, 2003
923
11
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
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

Well-Known Member
Nov 1, 2003
923
11
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
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.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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!
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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

Member
Jan 28, 2015
21
4
53
cPanel Access Level
Root Administrator
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":

Code:
# 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.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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

Well-Known Member
Nov 1, 2003
923
11
168
Northern Ontario, Canada
cPanel Access Level
Root Administrator
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

Administrator
Staff member
Apr 11, 2011
47,910
2,215
363
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.
 
  • Like
Reactions: verdon