Community
Participate
Working Groups
Currently, there are many file/directory permissions on eclipse downloads with 'common' group access. I do mean specifically /home/data/httpd/download.eclipse.org/eclipse I think these should all be the 'eclipse.platform.releng' group, instead (well, except maybe those where the group is root?) I think "common" means any committer can write there, right? Now ... let me see if I can recall all the steps to do this right :) A. make a mass change to group ownership B. set the guid bit for directorories so new directories or files created with have the same group ownder. C. make similar changes to any ACL's that control access there for those who have exceeded the maximum number of linux groups allows? Both the ACL, and the Default ACL? Well, maybe "A" should be done last? to avoid timing issues? Any other ideas? FWIW, this isn't just book keeping, but think we encountered a case of someone accidentally changing a milestone repo.
(In reply to comment #0) I really need to stop writing while hungry ... or learn to proof ready better. Here's improved list of steps: A. set the GUID bit for directories so new directories or files created under that directory will have correct group owner assigned automatically by default. B. make similar change or addition to any ACL's that control access there, especially for those who have exceeded the maximum number of Linux groups allowed and are part of the ACL instead. Both the ACLs, and the Default ACL needs to be fixed. C. make recursive change to using chown -R (or similar) to fix group owner for any that are incorrect (especially if 'common' ... not sure if there are any others in use, besides 'eclipse.platform.releng' or 'root', but if so, I can't imagine why that would be needed). The current members of eclipse.platform.releng are dmegert,kmoir,cwindatt,ffusier,pwebster,johna,tzarna Does that cover everyone who needs "write/delete" access there?
(In reply to comment #1) > (In reply to comment #0) > The current members of eclipse.platform.releng are > dmegert,kmoir,cwindatt,ffusier,pwebster,johna,tzarna > Does that cover everyone who needs "write/delete" access there? Let me emphasize, I am _assuming_ the group owner should be eclipse.platform.releng. I've forgotten the general pattern the webmaster are (trying) to move to for consistency ... such as I suppose 'eclipse.platform' is another possibility? $ getent group eclipse.platform eclipse.platform:*:8777:mcq,dmegert,johna,kmoir,moberhuber,darin,mrennie,aniefer,dj,sfranklin,gheorghe,pwebster Or is there some other "admin" group in use by the platform?
added long list of people to CC who probably know better then I, if the Platform is using a particular pattern of "group owner" since I am new to this group :/
To cross reference, bug 374707 it the one where this was a "real problem' ... via email we established it was (pretty likely) an accident (bug) from a non-platform committer's script. Having the reduced number of people with write ability doesn't mean there won't still be such accidents, but the laws of probability would help it be less likely (since smaller group of people). I should also add ... in my long history of experience in webtools (and similar "releng" roles) these group ownerships occasionally get "messed up" and have to be "re-fixed" like once a year or so, such as bug 300296 documents one case.
(In reply to comment #0) > Currently, there are many file/directory permissions on eclipse downloads with > 'common' group access. I do mean specifically > > /home/data/httpd/download.eclipse.org/eclipse > > I think these should all be the 'eclipse.platform.releng' group, instead (well, > except maybe those where the group is root?) +1 > I think "common" means any committer can write there, right? Correct. > > Now ... let me see if I can recall all the steps to do this right :) > > A. make a mass change to group ownership I guess you can only do this if you're either root or the owner. > The current members of eclipse.platform.releng are > > dmegert,kmoir,cwindatt,ffusier,pwebster,johna,tzarna > Looks good to me, except that you also need to be added - but that's already in process. > I've forgotten the general pattern the webmaster are (trying) to move to for > consistency ... such as I suppose 'eclipse.platform' is another possibility? No, this group is used for other stuff these days (mostly older stuff which is in maintenance mode and not releng related) and should not be used for releng stuff. 'eclipse.platform.releng' is the correct group. > added long list of people to CC who probably know better then I, if the > Platform is using a particular pattern of "group owner" since I am new to > this group :/ David, this might help (but please note, that this list is not up-to-date - it captures the state when we migrated to Git): http://wiki.eclipse.org/index.php?title=Eclipse/PMC/Unix_Groups/New_ACLS_By_Project&oldid=228138
Ok, I've changed all of the 'common' group ownerships to 'eclipse.platform.releng'. I also made sure all directories had the setgid bit. Right now only Kim has more than 16 groups. David when you are elected to plaform.releng, please remind me(or webmaster) to setup an ACL so you have access. -M.
Thanks for fixing these quickly. And your speedy enablement of my committer credentials. Before becoming a committer, I confirmed I could no longer change things there ... and now that I am a committer, I can! Thanks very much.
This seems to be fixed for .../eclipse/updates but not .../eclipse/downloads You'll noticed I created some new "index.html" files recently under /home/data/httpd/download.eclipse.org/eclipse/downloads/ and they have "common" group. Similarly, under "drops4" it created a new directory with right group ownership drwxrwxr-x+ 9 david_williams eclipse.platform.releng 4K 2012-04-11 22:43 I20120411-2034/ But, everything under that directory has "common" group. Am I seeing or doing something wrong? Thanks,
Oh, and what I said in first line of comment 8 is not quite right. Again, it created the directory with right group ownership, /home/data/httpd/download.eclipse.org/eclipse/updates/4.2-I-builds/I20120411-2034 but not the stuff under it.
Missing setgid bit. Should be ok now. -M.
Have discovered today another problem ... even though group permissions fixed for "newly created" directories (I think), many existing ones do not have group "write" permissions For example I need to update 3.8-I-builds (modify parts, as well as add subdirectories and eventually delete). under /home/data/httpd/download.eclipse.org/eclipse/updates drwxr-sr-x+ 15 kmoir eclipse.platform.releng 4K 2012-03-20 16:35 3.8-I-builds/ I see a couple of ways to solve (would appreciate 3.8-I-builds be done first, since rest might take a while :) One possible way is to find everything under /home/data/httpd/download.eclipse.org/eclipse/ and if it it is owned by group eclipse.platform.releng then make sure its group permissions are g=rwx Another possible way ... make me owner of everything where kim is/used to be owner :) Pretty sure she's not planning on making udpates. Then some of these types of changes I could make myself (I think). In parallel, I might be able to get around the 3.8-I-builds problem ... but, the above should be done for /home/data/httpd/download.eclipse.org/eclipse/ (at least where groups is eclipse.platform.releng which should be most everything. If you find 'common' is (again) group anywhere, that should be changed to eclipse.platform.releng (sorry for the out of order rambling note).
I think this deserves "blocker" status. In won't let me create a directory [15:41:34] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/updates/3.8-I-builds $ mkdir temptest mkdir: cannot create directory `temptest': Permission denied and our update sites are pretty critical for a lot of people. Note the "4.2" version of these directories look right ... maybe they were created after the initial fixes? But, all of the 3.8 ones need fixing ... well, except for the "tempbackup" I created, which shows new directories are created correctly. (I was just going to move tempback to be the real thing ... but, naturally, won't let me delete the original). [15:43:28] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/updates/4.2-I-builds $ ll ../4.2* -d drwxrwsr-x+ 2 kmoir eclipse.platform.releng 4K 2012-01-27 19:06 ../4.2/ drwxrwxr-x+ 3 david_williams eclipse.platform.releng 4K 2012-04-19 21:23 ../4.2.0-N-builds/ drwxrwsr-x+ 10 pwebster eclipse.platform.releng 4K 2012-04-19 13:37 ../4.2-I-builds/ drwxrwsr-x+ 12 pwebster eclipse.platform.releng 4K 2012-03-20 11:54 ../4.2milestones/ drwxrwsr-x+ 4 david_williams eclipse.platform.releng 4K 2012-04-19 01:46 ../4.2-N-builds/ [15:43:40] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/updates/4.2-I-builds $ ll ../3.8* -d drwxr-sr-x+ 2 kmoir eclipse.platform.releng 4K 2011-11-22 11:28 ../3.8/ drwxr-sr-x+ 15 kmoir eclipse.platform.releng 4K 2012-03-20 16:35 ../3.8-I-builds/ drwxrwsr-x+ 15 david_williams eclipse.platform.releng 4K 2012-04-20 14:19 ../3.8-I-builds-tempbackup/ drwxr-sr-x+ 9 kmoir eclipse.platform.releng 4K 2012-03-16 17:35 ../3.8milestones/ drwxr-sr-x+ 7 kmoir eclipse.platform.releng 4K 2012-03-22 17:30 ../3.8-N-builds/ [15:43:58] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/updates/4.2-I-builds
Actually I suspect the issue is ACLs(again): >getfacl 3.8-I-builds/ # file: 3.8-I-builds/ # owner: kmoir # group: eclipse.platform.releng # flags: -s- user:david_williams:rwx #effective:r-x group::r-x mask::r-x I've walked the updates directory and updated the ACL mask and the group ownership. Unrelated question: why is there a link to /download.eclipse.org/tools in download.eclipse.org/eclipse ? -M
(In reply to comment #13) > > I've walked the updates directory and updated the ACL mask and the group > ownership. > > Unrelated question: why is there a link to /download.eclipse.org/tools in > download.eclipse.org/eclipse ? > > -M Thank you. That works. About the tools link ... I have no idea why its there. I think you can remove it, and we'll find out if anything breaks :)
We'll count this one as fixed ... I'll open a new one the next time it happens (and, you know it will! :)
