Last modified: 2014-11-09 18:22:23 UTC
Created attachment 17065 [details] Inserted image with 403 Forbidden In betalabs Open any page in VE - insert media-> type 'paragon'(no quotes) Select an image of a plate(may need to scroll down). The image will be successfully inserted but it won't displayed - look at the attached screenshot. Remote Address:208.80.155.136:80 Request URL: http://upload.beta.wmflabs.org/wikipedia/en/thumb/6/6e/Paragon_2725918194_4227b11610.jpg/220px-Paragon_2725918194_4227b11610.jpg Request Method: GET Status Code: HTTP/1.1 403 Forbidden
http://en.wikipedia.beta.wmflabs.org/wiki/File:Paragon_2725918194_4227b11610.jpg "Size of this preview" links also trigger 403s Not an issue in the MediaWiki codebase but server stuff, hence moving to "Wikimedia Labs > deployment-prep (beta)"
This is an occasional problem with file permissions on the shared NFS directories used for beta's image uploads: deployment-bastion:~ bd808$ ls -ld /data/project/upload7/wikipedia/en/thumb/6/6e/Paragon_2725918194_4227b11610.jpg drwx------ 2 pybal-check apache 4096 Nov 6 23:54 /data/project/upload7/wikipedia/en/thumb/6/6e/Paragon_2725918194_4227b11610.jpg/ This seems to be caused in part by mismatched user ids across the beta cluster: * deployment-bastion: uid=48(apache) gid=48(apache) groups=48(apache) * deployment-bastion: uid=997(pybal-check) gid=52067(pybal-check) groups=52067(pybal-check) * deployment-mediawiki01: uid=997(apache) gid=48(apache) groups=48(apache) * deployment-mediawiki02: uid=997(apache) gid=48(apache) groups=48(apache) It also looks like the umask is not set well in some path that handles actually creating new directory paths. The best long term fix for this is to setup a Swift cluster in beta (bug 62835). The short term hack is to chmod/chown the files under /data/project/upload7.
Ran `chmod -R =rwX /data/project/upload7` to fix all file permissions.
Be aware that doing so has given write permission to any authenticated user. This may not be a catastrophe in practice, but it has security impact.
(In reply to Marc A. Pelletier from comment #4) > Be aware that doing so has given write permission to any authenticated user. > This may not be a catastrophe in practice, but it has security impact. This has been the fix for this particular issue as long as I've been helping in beta. I agree that chmod 0777 is a lame solution, but the uid/gid mismatches and NFS4 acls are a bit of a blocker to proper management of the shared file permissions.
NFSv4 doesn't actually require UID concordance so long as the user /name/ exists on the NFS server do that it doesn't fall back to numerical IDs - the proper solution to this is to make certain that any user or group that owns files in the shared filesystem exist on the NFS servers. In the general Labs case, this is done through LDAP - but users and groups coming from Debian packages need to either be added (before installation) to LDAP or added to the NFS servers.
(In reply to Marc A. Pelletier from comment #6) > NFSv4 doesn't actually require UID concordance so long as the user /name/ > exists on the NFS server do that it doesn't fall back to numerical IDs - the > proper solution to this is to make certain that any user or group that owns > files in the shared filesystem exist on the NFS servers. > > In the general Labs case, this is done through LDAP - but users and groups > coming from Debian packages need to either be added (before installation) to > LDAP or added to the NFS servers. Bug 73206 opened to track this issue.
