Bugzilla – Full Text Bug Listing
| Summary: | need group (and permissions) fixed on eclipse downloads | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | john.arthorne |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Williams
Ok the permissions should be all fixed. -M. Still not right. You might have fixed permissions of existing files (which is necessary), but the problem is that new things do now have the write permissions/groups created for them.
For example, under these two direcotories:
[19:16:56] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/downloads
$ ll drops* -d
drwxrwsr-x+ 17 kmoir eclipse.platform.releng 4K 2012-05-09 23:42 drops/
drwxrwsr-x+ 16 pwebster eclipse.platform.releng 4K 2012-05-09 22:01 drops4/
You can see the most recent I-build created last night (the evening after your last comment) was created without group "write" and without group GUID bit set, such as
[19:18:47] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/downloads/drops4
$ ll -d I20120509-1900/
drwxr-xr-x+ 10 david_williams eclipse.platform.releng 12K 2012-05-10 11:45 I20120509-1900/
so end result is files under _that_ have 'common' group associated with them
-rw-rw-r--+ 1 david_williams common 42K 2012-05-10 11:45 index.php
I know this is a pain, but I know there must be a way to solve this ... I think something is wrong with ACLs?
Similar problems with "update sites"
[19:22:04] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/updates/4.2-I-builds
drwxrwsr-x+ 5 david_williams eclipse.platform.releng 4K 2012-05-09 22:33 I20120503-1800/
drwxrwxr-x+ 5 david_williams eclipse.platform.releng 4K 2012-05-09 22:34 I20120509-1900/
$ cd I20120509-1900/
[19:22:50] david_williams@build:/home/data/httpd/download.eclipse.org/eclipse/updates/4.2-I-builds/I20120509-1900
$ ll
total 608K
-rw-rw-r--+ 1 david_williams common 63K 2012-05-09 22:34 artifacts.jar
drwxrwxr-x+ 2 david_williams common 12K 2012-05-09 22:34 binary/
-rw-rw-r--+ 1 david_williams common 353K 2012-05-09 22:34 content.jar
drwxrwxr-x+ 2 david_williams common 20K 2012-05-09 22:35 features/
drwxrwxr-x+ 2 david_williams common 144K 2012-05-09 22:36 plugins/
David, I'm not sure how you're creating new directories and files? Something in the process is specifically asking that the guid bit be unset. All we (webmasters) can do is set rws on the directory. No ACL will make the guid bit stick if your upload/copy process is requesting it be unset. (In reply to comment #3) > David, I'm not sure how you're creating new directories and files? Something in > the process is specifically asking that the guid bit be unset. All we > (webmasters) can do is set rws on the directory. No ACL will make the guid bit > stick if your upload/copy process is requesting it be unset. Well, all I'm doing is using rsync. Could something be "off" with its settings/config that's causing this? I have confirmed that if I simply 'mkdir test' that it has the right perms: drwxrwsr-x+ 2 david_williams eclipse.platform.releng 4K 2012-05-11 11:03 test/ But if I use rsync, even rsync --no-perms (which should be the default) then it is create without the GUID bit set. rsync -r --no-perms ~/temp/test . drwxrwxr-x+ 2 david_williams eclipse.platform.releng 4K 2012-05-11 11:17 test And moderately sure it should just "inherit" the parents GUID bit in that case. In fact, lucky we have a test case :) ... I tested this in "webtools" downloads area, since have done it there for years. With the same "test" directory I used above, in the directory /home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.4.0 a simple rsync -r ~/temp/test . give the results I'd expect drwxrwsr-x 2 david_williams webtools 4K 2012-05-11 11:28 test/ So .. what's different about /home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.4.0 and /home/data/httpd/download.eclipse.org/eclipse/downloads/drops4 $ getfacl /home/data/httpd/download.eclipse.org/eclipse/downloads/drops4 getfacl: Removing leading '/' from absolute path names # file: home/data/httpd/download.eclipse.org/eclipse/downloads/drops4 # owner: pwebster # group: eclipse.platform.releng # flags: -s- user::rwx user:david_williams:rwx group::rwx mask::rwx other::r-x default:user::rwx default:user:david_williams:rwx default:group::rwx default:mask::rwx default:other::r-x $ getfacl /home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.4.0/ getfacl: Removing leading '/' from absolute path names # file: home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.4.0/ # owner: canderson # group: webtools # flags: -s- user::rwx group::rwx other::r-x Looks related to "mask"? To me. (combined with some rsync setting?) The lack of a 'mask' entry really only implies that there are no acls on /home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.4.0/ . I did some digging and came across this: The ACL_MASK entry denotes the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP. It appears that the only way to remove the mask is to remove all the ACLS. Of course if I remove the ACLs, then you can't write there. I also tried granting the setgid bit via the mask, but rwx seems to be the upper bounds of it's permissions. I'm starting to wonder if this is the old 16-groups-over-nfs limit again. I can see 2 options: 1) Try publishing on dev(since it's kernel is ok with 16+ groups) 2) Add a chgrp and chmod to your publishing scripts to fix the bad groups. -M. (In reply to comment #5) > The lack of a 'mask' entry really only implies that there are no acls on > /home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.4.0/ > . > > I did some digging and came across this: > > The ACL_MASK entry denotes the maximum access rights that can be granted by > entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP. > Just to document "mask weirdness" I can't write to one of "my" directories on build machine: note the #effective "comment" ... I guess there the mask needs g=w added to "user" mask. (I'm just moaning about ACLs, I might be able to fix that myself, and/or its just in the way for one little thing, easily worked around). $ getfacl /opt/public/eclipse/eclipse3I/build/supportDir/org.eclipse.releng.eclipsebuilder getfacl: Removing leading '/' from absolute path names # file: opt/public/eclipse/eclipse3I/build/supportDir/org.eclipse.releng.eclipsebuilder # owner: e4Build # group: eclipse.platform.releng # flags: -s- user::rwx user:david_williams:rwx #effective:r-x user:e4Build:rwx #effective:r-x user:hudsonBuild:rwx #effective:r-x group::rwx #effective:r-x mask::r-x other::r-x default:user::rwx default:user:david_williams:rwx default:user:e4Build:rwx default:user:hudsonBuild:rwx default:group::rwx default:mask::rwx default:other::r-x > I'm starting to wonder if this is the old 16-groups-over-nfs limit again. Maybe interacts with it, but it works for webtools, or me, so would that be because it interacts with mask ... or the 16 group limit mean something like "the first 16 groups are ok", but any group over 16 won't work? If that's all it is, I should look to shed some groups! :) > I can see 2 options: > > 1) Try publishing on dev(since it's kernel is ok with 16+ groups) You mean via SSH I assume? The "paths" would look the same? I didn't think we could SSH to dev any longer? > 2) Add a chgrp and chmod to your publishing scripts to fix the bad groups. You mean before I rsync? On build machine version? I have tried "after" on "downloads" and it won't let me change those. (I think, though might be confusing myself). Thanks for your help.
> If that's all
> it is, I should look to shed some groups! :)
Seriously, I'm in 20 groups, I could find 4 or 5 to "resign" from if that'd fix hassles like this.
I see I'm in webtools.all (what's that? Different from "webtools"?)
And, I am in webtools.datatools, but thought I'd "resigned" from there, when Carl took over as PL (of that quiescent project with one committer).
There are several others I could resign from if that'd solve this problem.
(In reply to comment #7) > > If that's all > > it is, I should look to shed some groups! :) > > Seriously, I'm in 20 groups, I could find 4 or 5 to "resign" from if that'd fix > hassles like this. > > I see I'm in webtools.all (what's that? Different from "webtools"?) > And, I am in webtools.datatools, but thought I'd "resigned" from there, when > Carl took over as PL (of that quiescent project with one committer). > There are several others I could resign from if that'd solve this problem. But, I am worried its more complicated than that (or, simpler?) since "it works" on the webtools directories. Another complication might have been bug 379359. While I don't think that explains it entirely (obviously many interactions) I have observed at times that ANY change to group permissions "undoes" the GUID bit. So, if rsync was "changing" the group write permission, that might cause it to undo the GUID bit. Perhaps, if group matches exactly rws before rsync is called, then it will all end up just fine. (Will be a while before I can confirm). (In reply to comment #6) >I'm just moaning about ACLs, I might be able to fix > that myself, and/or its just in the way for one little thing, easily worked > around I've updated the mask on the /opt/public/eclipse tree. > "the first 16 groups are ok", but any group over 16 won't work? That's about the size of it. > You mean via SSH I assume? The "paths" would look the same? I didn't think we > could SSH to dev any longer? You can't login but you can use sftp and there are some custom rsync entries that Kim/Sonia were using that you were added to. > You mean before I rsync? On build machine version? I have tried "after" on > "downloads" and it won't let me change those. (I think, though might be > confusing myself). And that is most definitely the 16 group limit. From the internet: "To change the group ownership of a file to another group you have to be a member of that group or root " Examples(on build): david_williams>chgrp eclipse.platform.releng .git chgrp: changing group of `.git': Operation not permitted david_williams>chgrp webtools.sourceediting .git chgrp: changing group of `.git': Operation not permitted Those are groups 20 and 17 respectively david_williams> chgrp webtools.releng .git david_williams> Group #16 -M. I have officially resigned from 5 subprojects: http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg08390.html webtools.datatools webtools.ejbtools webtools.jeetools webtools.servertools webtools.webservices I'm sure this will "percolate" through the system and eventually I'd be removed from these unix groups, but to the extent you can "speed up" that process, it would be appreciated. That should put me at 15 groups, and we'll put all these theories to the test :) [Not sure, if I'd then also _have_ to be removed from ACLs, or if that's just an optional "not needed" step that could be done later?]. Ok, I asked EMO legal to let me remove you from these groups while we wait for everything to follow the usual path. You now have 15 groups. -M. The latest build, was rsync'd and maintain/gained the expected permissions. /home/data/httpd/download.eclipse.org/eclipse/downloads/drops4/I20120516-1900/ drwxrwsr-x+ 10 david_williams eclipse.platform.releng 4K 2012-05-16 21:38 I was able to change group and g+w on several on the directories I owned, so think we all set now, in this area. i.e. do not need GUID bit set on existing ones that don't have it. I see the ACLs are still in place ... if there's any advantage to removing me that'd be fine ... but also ok to leave ... I'm not sure what difference is. I will need a little help for "archives" but that's a technically a separate issue so will open a new bug. |