59217 2004-08-02 19:23 0000 Zope 2.7.2 - Permissions on /usr/lib/zope-2.7.2 set incorrectly 2004-09-20 04:19:32 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified Sparc Linux RESOLVED FIXED P2 major --- 1 jtb68@netprodigy.com net-zope@gentoo.org jesse@boldandbusted.com jtk@yahoo.com jtb68@netprodigy.com 2004-08-02 19:23:24 0000 I performed an ACCEPT_KEYWORDS=~sparc emerge zope For some reason, the group was set to "root" for the entire /usr/lib/zope-2.7.2 tree. The system is completely up to date (I ran 'emerge world' recently). I also managed to reproduce this on a X86 machine, which is a little less up to date (GLSA's have been updated, but not much else in about two months). Reproducible: Always Steps to Reproduce: I did have Zope previously installed on the machine, performed the following: 1) "emerge unmerge zope" 2) rm -Rf /usr/lib/zope-2.7.2 3) rm -Rf /var/lib/zope 4) rm /etc/conf.d/zope-2.7.2 5) rm /etc/init.d/zope-2.7.2 6) userdel zope 7) groupdel zope 8) ACCEPT_KEYWORDS=~x86 emerge zope 9) ls -al /usr/lib/zope-2.7.2 Actual Results: odin / # ls -al /usr/lib/zope-2.7.2/ total 60 drwxr-x--- 6 root root 4096 Aug 2 22:15 . drwxr-xr-x 87 root root 40960 Aug 2 22:15 .. drwxr-x--- 2 root root 4096 Aug 2 22:15 bin drwxr-x--- 2 root root 4096 Aug 2 22:15 import drwxr-x--- 3 root root 4096 Aug 2 22:15 lib drwxr-x--- 9 root root 4096 Aug 2 22:15 skel Once I created a Zope instance, Zope would fail to continue startup once it dropped privs and switched to the "zope" user due to the inability to read program files. Specifically, it failed when it tried to import /usr/lib/zope-2.7.2/lib/python/Zope/Startup/misc/lock_file.py (unable to traverse past zope-2.7.2). This wasn't obvious (no logging anywhere) until I started /var/lib/zope/zope-2.7.2/bin/zopectl and issued "foreground". Expected Results: Group ownership on the /usr/lib/zope-2.7.2 tree should be set to "zope" Interestingly enough, if I skip steps #6 and #7 and re-emerge, it appears to set the group ownership correctly. Maybe the user/group is getting created too late in the process for it to happen the first time around? However, it won't modify the ownership on an existing directory tree, you must remove the /usr/lib/zope-2.7.2 tree and leave the zope user+group in place. After doing steps 1-5,8-9 or 2-5,8-9 in the 'Steps to reproduce': odin / # ls -al /usr/lib/zope-2.7.2/ total 60 drwxr-x--- 6 root zope 4096 Aug 2 22:20 . drwxr-xr-x 87 root root 40960 Aug 2 22:20 .. drwxr-x--- 2 root zope 4096 Aug 2 22:20 bin drwxr-x--- 2 root zope 4096 Aug 2 22:20 import drwxr-x--- 3 root zope 4096 Aug 2 22:20 lib drwxr-x--- 9 root zope 4096 Aug 2 22:20 skel stan@saticed.me.uk 2004-08-04 06:09:18 0000 The permissions are set in the setup_security called at the end of src_install. The zope group isn't added until after this has run (in pkg_preinst) - moving the setup_security call to pkg_postinst could sort it out fodder@mattturner.us 2004-08-08 16:57:42 0000 I can confirm having similar permissions-related startup issues with Zope 2.7.2 on x86. This problem may not be confined to Sparc alone. Only by running zopectl with the "foreground" command did I determine that Zope could not reach the Python packages that it needed. Altering group ownership to "zope" for the /usr/lib/zope-2.7.2 tree solved the problem. carter.smithhart@gmail.com 2004-08-10 22:00:36 0000 Created an attachment (id=37193) Patch to fix bug 59217 and 58562 Changes include: - ZS_DIR and ZI_DIR should no longer have double slashes at beginning (fixes bug 58562) - all dir variables now have END slashes. Fixed a few places where it was inconsistant. - moved setup_security call from src_install into pkg_preinst. If setup_security waits until pkg_postinst, the files are already merged into the system. (fixes bug #59217) Suggested change: - a better way (?) to correctly delete .default. carter.smithhart@gmail.com 2004-08-10 22:09:16 0000 Another thing... After I made the necessary fixes to the ebuild, I tried doing an emerge zope (while zope-2.7.2 was still installed) and none of the permissions got fixed.... Why is that? Shouldn't the permissions from an ebuild's image overwrite whatever is on the system? Is this a philosophical question that should be moved to the forum? Or is this an "emerge" tool bug? So what I had to do is emerge -C zope-2.7.2, then emerge zope and the permissions were fixed.. Weird.. I challenge somebody else to try this and see if I'm right. kerframil@gmail.com 2004-08-17 09:22:43 0000 > So what I had to do is emerge -C zope-2.7.2, then emerge zope and the permissions > were fixed.. Weird.. I challenge somebody else to try this and see if I'm right. I tried out the zope-2.7.2.ebuild, having applied your patch, and can confirm that this is indeed the case. I removed /usr/lib/zope-2.7.2 prior to re-emerging to rectify the problem. kerframil@gmail.com 2004-08-17 09:49:00 0000 By the way, these are the components I am now using (in the net-zope category): net-zope/epoz-0.8.2 * net-zope/plonetranslations-0.1 * net-zope/formulator-1.6.2 * net-zope/cmfquickinstallertool-1.5.0 * net-zope/ploneerrorreporting-0.11 * net-zope/plone-2.0.4 * net-zope/portaltransforms-1.0.4 * net-zope/cmfactionicons-0.9 * net-zope/cmf-1.4.7 * net-zope/groupuserfolder-2.0.1 * net-zope/placelesstranslationservice-1.0_rc8 * net-zope/zope-2.7.2 * net-zope/cmfformcontroller-1.0.3_beta * net-zope/btreefolder2-1.0.1 * net-zope/externaleditor-0.8 * net-zope/archetypes-1.2.5_rc5 * kerframil@gmail.com 2004-08-17 09:50:02 0000 Oops, wrong bug - meant that comment for bug 51825 ... sorry. jmjoseph@andrew.cmu.edu 2004-09-10 06:33:46 0000 This bug has been stagnant for nearly a month now. As the current ebuild is unusable and this patch works, can we get this patch into portage sooner than later? It's not as if it's doing anything crazy. It's fine if it remains masked ~x86 while any other issues are sorted out. Thanks. -Jacob lanius@gentoo.org 2004-09-11 13:43:00 0000 *** Bug 58562 has been marked as a duplicate of this bug. *** lanius@gentoo.org 2004-09-11 14:07:44 0000 finally applied in zope-2.7.2-r1 jwashin@vt.edu 2004-09-19 05:05:06 0000 Apparently, one too many slashes were removed in the ebuild. zope-2.7.2-r2 improperly installs itself into /usr/libzope-2.7.2 instead of usr/lib/zope-2.7.2 Easy to fix with mv. jesse@boldandbusted.com 2004-09-19 16:11:29 0000 Wow, got bitten by the "too many slashes" myself. Too bad I zapped my entire zope installation in attempting to fix that before seeing this bug... :( batlogg@gentoo.org 2004-09-20 04:19:32 0000 added the missing slash - sorry :) NOTE: the ebuild doesn't require zope-config as dependency. you still can use it, but it's not default anymore. the permissions in the /usr/lib are more restrictive... we treat zope like a "normal" library. 37193 2004-08-10 22:00 0000 Patch to fix bug 59217 and 58562 zope-2.7.2.ebuild.patch text/plain LS0tIC91c3IvcG9ydGFnZS9uZXQtem9wZS96b3BlL3pvcGUtMi43LjIuZWJ1aWxkCTIwMDQtMDgt MDEgMTU6MzU6NDkuMDAwMDAwMDAwIC0wNzAwCisrKyAvdXNyL2xvY2FsL3BvcnRhZ2UvbmV0LXpv cGUvem9wZS96b3BlLTIuNy4yLmVidWlsZAkyMDA0LTA4LTEwIDIxOjU0OjMwLjEyOTE2NzExMiAt MDcwMApAQCAtMTAsNyArMTAsNyBAQAogTElDRU5TRT0iWlBMIgogU0xPVD0iJHtQVn0iCiAKLUtF WVdPUkRTPSJ+eDg2IH5zcGFyYyB+cHBjIH5hbHBoYSB+YW1kNjQiCitLRVlXT1JEUz0ieDg2IH5z cGFyYyB+cHBjIH5hbHBoYSB+YW1kNjQiCiBJVVNFPSJ1bmljb2RlIgogCiBSREVQRU5EPSI9ZGV2 LWxhbmcvcHl0aG9uLTIuMyoiCkBAIC0yNiwxMCArMjYsMTAgQEAKIFpVSUQ9em9wZQogWkdJRD16 b3BlCiBaR0lEX0lOU1Q9IiQoZWNobyAke1BOfS0ke1BWfSB8IHNlZCAtZSAncy9cLi9fL2cnICki Ci1aU19ESVI9JHtST09UfS91c3IvbGliLwotWklfRElSPSR7Uk9PVH0vdmFyL2xpYi96b3BlLwor WlNfRElSPSR7Uk9PVCUvfS91c3IvbGliLworWklfRElSPSR7Uk9PVCUvfS92YXIvbGliL3pvcGUv CiBaU0VSVkRJUj0ke1pTX0RJUn0ke1BOfS0ke1BWfS8KLVpJTlNURElSPSR7WklfRElSfSR7UE59 LSR7UFZ9CitaSU5TVERJUj0ke1pJX0RJUn0ke1BOfS0ke1BWfS8KIAogUkNOQU1FPXpvcGUuaW5p dGQKIApAQCAtNDQsNyArNDQsNiBAQAogIyBQYXJhbWV0ZXJzOgogIyAgJDEgPSBpbnN0YW5jZSBk aXJlY3RvcnkKICMgICQyID0gZ3JvdXAKLQogc2V0dXBfc2VjdXJpdHkoKSB7CiAJIyBUaGUgb2xk IHZlcnNpb24gbWFkZSBldmVyeXRoaW5nIG93bmVkIGJ5IHpvcGU6JHtERUZBVUxUX0lOU1RBTkNF X0dJRH0sCiAJIyBhbmQgZ3JvdXAtd3JpdGFibGUuIFRoaXMgaXMgbGlrZSBtYWtpbmcgZXZlcnl0 aGluZyBpbiBuZXQtd3d3L2FwYWNoZTIgCkBAIC01Myw2ICs1Miw3IEBACiAJIyBieSB0aGUgem9w ZSBncm91cCwgb2Ygd2hpY2ggdGhlIHpvcGUgdXNlciBpcyBhIG1lbWJlciwgc28gdGhhdCBydW5u aW5nCiAJIyB6b3BlIGluc3RhbmNlcyB3aWxsIGJlIGFibGUgdG8gcmVhZCBldmVyeXRoaW5nLgog CSMgLS0gQW5keSBEdXN0bWFuCisKIAljaG93biAtUiByb290OiR7Mn0gJHsxfQogCWNobW9kIC1S IGcrcixnLXcsby1yd3ggJHsxfQogfQpAQCAtNjIsMTEgKzYyLDExIEBACiAJaWYgWyAtZCAke1pJ TlNURElSfSBdIDsgdGhlbgogCQlkaWUgIkRlZmF1bHQgaW5zdGFuY2UgZGlyZWN0b3J5ICgke1pJ TlNURElSfSBhbHJlYWR5IGV4aXN0cyEiCiAJZmkKLQlpZiBbIC1mICR7WklfRElSfS8uZGVmYXVs dCBdIDsgdGhlbgotCQlkZWZfaW5zdGFuY2U9YGNhdCAke1pJX0RJUn0vLmRlZmF1bHRgCi0JCWRp ZSAiRGVmYXVsdCBpbnN0YW5jZSBmaWxlICgke1pJX0RJUn0vLmRlZmF1bHQgYWxyZWFkeSBleGlz dHMgLT4gJGRlZl9pbnN0YW5jZSIKKwlpZiBbIC1mICR7WklfRElSfS5kZWZhdWx0IF0gOyB0aGVu CisJCWRlZl9pbnN0YW5jZT1gY2F0ICR7WklfRElSfS5kZWZhdWx0YAorCQlkaWUgIkRlZmF1bHQg aW5zdGFuY2UgZmlsZSAoJHtaSV9ESVJ9LmRlZmF1bHQgYWxyZWFkeSBleGlzdHMgLT4gJGRlZl9p bnN0YW5jZSIKIAlmaQotCWVpbmZvICJDcmV0aW5nIGRlZmF1bHQgem9wZSBpbnN0YW5jZSBhdCAk e1pJTlNURElSfSB3aXRoIGNvbW1hbmQ6IgorCWVpbmZvICJDcmVhdGluZyBkZWZhdWx0IHpvcGUg aW5zdGFuY2UgYXQgJHtaSU5TVERJUn0gd2l0aCBjb21tYW5kOiIKIAllaW5mbyAiL3Vzci9zYmlu L3pvcGUtY29uZmlnIC0tenNlcnY9JHtaU0VSVkRJUn0gLS16aW5zdD0ke1pJTlNURElSfSAtLXpn aWQ9JHtaR0lEX0lOU1R9IC0temluaXR1c2VyIgogCWV3YXJuICJEZWZhdWx0IGFkbWluIHVzZXIg Y3JlYXRlZCB3aXRoIHBhc3N3b3JkIGFkbWluLiBQbGVhc2UgY2hhbmdlIGl0LiIKIAkvdXNyL3Ni aW4vem9wZS1jb25maWcgLS16c2Vydj0ke1pTRVJWRElSfSAtLXppbnN0PSR7WklOU1RESVJ9IC0t emdpZD0ke1pHSURfSU5TVH0gLS16aW5pdHVzZXIKQEAgLTc3LDYgKzc3LDkgQEAKIAllbmV3Z3Jv dXAgJHtaR0lEfSAyNjEKIAl1c2VybW9kIC1nICR7WkdJRH0gJHtaVUlEfSAyPiYxID4vZGV2L251 bGwgfHwgXAogCWVuZXd1c2VyICR7WlVJRH0gMjYxIC9iaW4vYmFzaCAke1pTX0RJUn0gJHtaR0lE fQorCisgICAgICAgICNbY3NdIE1vdmVkIHNldHVwX3NlY3VyaXR5IGhlcmUgdG8gZml4IEJ1ZyAj NTkyMTcKKyAgICAgICAgc2V0dXBfc2VjdXJpdHkgJHtEfSR7WlNFUlZESVJ9ICR7WkdJRH0KIH0K IAogc3JjX3VucGFjaygpIHsKQEAgLTg3LDYgKzkwLDcgQEAKIH0KIAogc3JjX2NvbXBpbGUoKSB7 CisgICAgICAgICNbY3NdIFRPRE86IFpPUEVfRElSIHNob3VsZCBiZSBzb21ldGhpbmcgZWxzZS4u Li4KIAkuL2NvbmZpZ3VyZSAtLWlnbm9yZS1sYXJnZWZpbGUgLS1wcmVmaXg9JHtaT1BFX0RJUn0g fHwgZGllICJGYWlsZWQgdG8gY29uZmlndXJlLiIKIAllbWFrZSB8fCBkaWUgIkZhaWxlZCB0byBj b21waWxlLiIKIH0KQEAgLTExOSwxNSArMTIzLDEzIEBACiAJCWNkICR7U30KIAlmaQogCi0JbWFr ZSBpbnN0YWxsIFBSRUZJWD0ke0R9LyR7WlNFUlZESVJ9Ci0Jcm0gLXJmICR7RH0ke1pTRVJWRElS fS9kb2MKLQlkb3N5bSAke0RPQ0RFU1RUUkVFfSAke0R9JHtaU0VSVkRJUn0vZG9jCisJbWFrZSBp bnN0YWxsIFBSRUZJWD0ke0R9JHtaU0VSVkRJUn0KKwlybSAtcmYgJHtEfSR7WlNFUlZESVJ9ZG9j CisJZG9zeW0gJHtET0NERVNUVFJFRX0gJHtEfSR7WlNFUlZESVJ9ZG9jCiAKLQlza2VsPSR7RH0k e1pTRVJWRElSfS9za2VsCisJc2tlbD0ke0R9JHtaU0VSVkRJUn1za2VsCiAJZG9kaXIgL2V0Yy9p bml0LmQKIAljcCAke0ZJTEVTRElSfS8ke1BWfS96b3BlLmluaXRkICR7c2tlbH0vem9wZS5pbml0 ZAotCi0Jc2V0dXBfc2VjdXJpdHkgJHtEfSR7WlNFUlZESVJ9ICR7WkdJRH0KIH0KIAogcGtnX3Bv c3RpbnN0KCkgewpAQCAtMTQyLDggKzE0NCwxNSBAQAogCiAJIyBEZWxldGUgLmRlZmF1bHQgaWYg dGhpcyBlYnVpbGQgaXMgdGhlIGRlZmF1bHQuIHpwcm9kLW1hbmFnZXIgd2lsbAogCSMgaGF2ZSB0 byBoYW5kbGUgYSBtaXNzaW5nIGRlZmF1bHQ7Ci0JIyBUT0RPOiB0aGlzIHNob3VsZCBiZSBjaGVj a2VkCisgICAgICAgICMgVE9ETzogdGhpcyBzaG91bGQgYmUgY2hlY2tlZAogCXJtIC1mICR7Wklf RElSfS8uZGVmYXVsdAorCisgICAgICAgICMgVE9ETzogVmVyaWZ5IHRoaXMgaXMgcmlnaHQuCisg ICAgICAgICNpZiBbIC1lICR7WklfRElSfS5kZWZhdWx0IF07IHRoZW4KKyAgICAgICAgIyAgICAg ICAgaWYgWyAiJChjYXQgJHtaSV9ESVJ9LmRlZmF1bHQpIiA9ICIke1BOfS0ke1BWfSIgXTsgdGhl bgorICAgICAgICAjICAgICAgICAJcm0gLWYgJHtaSV9ESVJ9LmRlZmF1bHQKKyAgICAgICAgIyAg ICAgICAgZmkKKyAgICAgICAgI2ZpCiB9CiAKIHBrZ19jb25maWcoKSB7Cg==