Community
Participate
Working Groups
Trying to sign a jar without giving an output directory fails without notice, when the current directory is not group-writable. What's especially confusing is that I still get an E-mail saying "...files are now signed" although they are not. This is a regression since I didn't change my scripts and they always used to work fine. I also seem to remember that in the past, there used to be a message like "... not writable by user genie" but I cannot see that message now. Steps to reproduce: > ssh moberhuber@build.eclipse.org > cd /home/data/httpd/download-staging.priv/dsdp/tm > mkdir foo > chmod g-w foo > cd foo > cp ../bar.jar . > sign bar.jar mail > tail -f /home/data/httpd/download-staging.priv/arch/signer.log 2010-08-24 07:21:04 build QUEUE: Begin processing queue: 5969 1282648848:moberhuber:/home/data/httpd/download-staging.priv/dsdp/tm/foo/bar.jar:mail:/home/data/httpd/download-staging.priv/dsdp/tm/foo ======================= end of (5969) contents 2010-08-24 07:21:04: build QUEUE(5969): calling jarprocessor.jar for /home/data/httpd/download-staging.priv/dsdp/tm/foo/bar.jar Running Repack Sign on /home/data/httpd/download-staging.priv/dsdp/tm/foo/bar.jar java.io.FileNotFoundException: /home/data/httpd/download-staging.priv/dsdp/tm/foo/temp.bar.jar/bar.jar (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:205) at java.io.FileOutputStream.<init>(FileOutputStream.java:157) at org.eclipse.update.internal.jarprocessor.JarProcessor.processJar(JarProcessor.java:343) at org.eclipse.update.internal.jarprocessor.JarProcessor.process(JarProcessor.java:96) at org.eclipse.update.internal.jarprocessor.Main.runJarProcessor(Main.java:168) at org.eclipse.update.internal.jarprocessor.Main.main(Main.java:184) 2010-08-24 07:21:04: build QUEUE(5969): Finished processing queue. > jarsigner -verify bar.jar jar is unsigned. (signatures missing or not parsable)
Digging a little deeper, I now see why my scripts don't work any more. Apparently, the "mkdir" command does apply the "s" bit to make its folder group-writable, but the "mkdir -p" command does not. As a result, the folder in which I performed staging is not group-writable and it failed. This may be a regression due to the build server update. Steps to reproduce: > cd /home/data/httpd/download-staging.priv/dsdp/tm > mkdir foo > ls -la foo drwxrwsr-x+ 2 moberhuber dsdp-tmadmin 48 2010-08-24 07:27 foo > mkdir -p bar/baz > ls -la bar drwxr-sr-x+ 3 moberhuber dsdp-tmadmin 72 2010-08-24 07:27 bar
> Apparently, the "mkdir" command does apply the "s" bit to make its folder > group-writable, but the "mkdir -p" command does not. Wow, great find. Oddly, we have an explicit ACL that _should_ allow genie to write everywhere, but with the missing group write permission, it seems to be filtering out even the ACL: build:/home/data/httpd/download-staging.priv/dsdp/tm # getfacl bar # file: bar # owner: moberhuber # group: dsdp-tmadmin # flags: -s- user::rwx user:genie:rwx #effective:r-x <-- Why? user:hudsonbuild:rwx #effective:r-x group::rwx #effective:r-x mask::r-x other::r-x default:user::rwx default:user:genie:rwx default:user:hudsonbuild:rwx default:group::rwx default:mask::rwx default:other::r-x
I set the mask to rwx, and that fixed the problem of genie being unable to write. # setfacl -nRm m:rwx download-staging.priv build:/home/data/httpd/download-staging.priv/dsdp/tm # getfacl bar # file: bar # owner: moberhuber # group: dsdp-tmadmin # flags: -s- user::rwx user:genie:rwx user:hudsonbuild:rwx group::rwx mask::rwx other::r-x default:user::rwx default:user:genie:rwx default:user:hudsonbuild:rwx default:group::rwx default:mask::rwx default:other::r-x
The ACL seems to have taken care of this.
