Opened 15 years ago
Closed 15 years ago
#9811 closed defect (bug) (duplicate)
ftp for plugin update fails to set correct privileges if umask not 0022
Reported by: | lovingboth | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.7.1 |
Component: | Upgrade/Install | Keywords: | reporter-feedback needs-testing |
Focuses: | Cc: |
Description
If the ftp user's umask is not 0022, newly created directories and files may not be read-enabled for other users, such as the webserver.
Having umask 0022 is the default for many, but not all, ftp servers. vsftpd has a default of 0077, for example. This results in new files not being readable by anyone other than the user, and so if the webserver is running as its own/another user, WP cannot see them.
Possible solutions:
- WP should check umask, and change if necessary, prior to creating them.
- WP should chmod newly created files/directories to the prvileges it expects.
- WP should check privileges on newly created files/directories, and report a failure if they are not what it expects.
Change History (4)
#1
@
15 years ago
- Component changed from Plugins to Upgrade/Install
- Keywords reporter-feedback needs-testing added; plugin update permissions umask removed
- Milestone changed from Unassigned to 2.8
#2
follow-up:
↓ 3
@
15 years ago
This should still be current under trunk.. However I have a feeling the issue is not as expected, and could be due to this bug: #9274 (closed defect (bug): Filesystem Class for ftpext does not perform chmod for directories )
WordPress *should* chmod the direcories/files after creating them.
If someone with a server set up like that could test under trunk, that'd be great.
#3
in reply to:
↑ 2
@
15 years ago
Replying to DD32:
WordPress *should* chmod the direcories/files after creating them.
If someone with a server set up like that could test under trunk, that'd be great.
I've just tried it under trunk, and it does indeed set the directory privileges correctly despite the default umask being 077.
Thanks to the bug-fixer of 9274... I'll leave it to someone else to marked this as fixed or duplicate, as I'm not sure which is more appropriate.
Can you confirm the issue in trunk? There have been quite a few tickets that were reported related to Upgrade/Install and the HTTP component since 2.7.