Last modified: 2014-11-19 17:48:38 UTC
(Bryan Davis from <https://bugzilla.wikimedia.org/show_bug.cgi?id=73102#c3>) > Ran `chmod -R =rwX /data/project/upload7` to fix all file permissions. (Marc A. Pelletier from <https://bugzilla.wikimedia.org/show_bug.cgi?id=73102#c4>) > 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. (Bryan Davis from <https://bugzilla.wikimedia.org/show_bug.cgi?id=73102#c5>) > (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. (Marc A. Pelletier from <https://bugzilla.wikimedia.org/show_bug.cgi?id=73102#c6>) > 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.
It should be sufficient for the MediaWiki runtime user (apache) to have read/write for the files and directories under the /data/project/upload7 NFS share. All hosts in the beta cluster should be made to agree on the uid of the apache user. This would probably involve creating an apache user in ldap, fixing all beta hosts to use that user instead of a local user and then fixing the shared file ownership to be 0775 apache:apache.
We had system users created in LDAP already, bug 66575 for cxserver and bug 63329 for parsoid. Maybe we need to create in LDAP an apache user with uid 48 and a group with gid 48.
*** Bug 73309 has been marked as a duplicate of this bug. ***
Per duplicate bug 73309, this blocks Bug 73229 - beta labs: "error while storing the file in the stash.'
root@deployment-bastion:/home/reedy# add-ldap-group --gid=48 apache Traceback (most recent call last): File "/usr/local/sbin/add-ldap-group", line 120, in <module> main() File "/usr/local/sbin/add-ldap-group", line 38, in main ldapSupportLib.setBindInfoByOptions(options, parser) File "/usr/local/lib/python2.7/dist-packages/ldapsupportlib.py", line 80, in setBindInfoByOptions self.binddn = self.getLdapInfo('USER', '/etc/ldap/.ldapscriptrc') File "/usr/local/lib/python2.7/dist-packages/ldapsupportlib.py", line 103, in getLdapInfo for line in f: UnboundLocalError: local variable 'f' referenced before assignment What do you give for a pub key? add-ldap-user --ui=48 --guid=48 apache ?????
Glancing at the source code of add-ldap-group, it seems to expect the existence of the /etc/ldap/.ldapscriptrc file, which would include the credentials to connect to LDAP. There are other options to provide the credentials.
Sam, that needs to be done on the whole labs LDAP. We probably don't have any credential there.