Bug 59217 – Zope 2.7.2 - Permissions on /usr/lib/zope-2.7.2 set incorrectly

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Jeff Balderson 2004-08-02 19:23:24 UTC]

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

[Comment 1 stan 2004-08-04 06:09:18 UTC]

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

[Comment 2 Matt Turner 2004-08-08 16:57:42 UTC]

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.

[Comment 3 Carter Smithhart 2004-08-10 22:00:36 UTC]

Created attachment 37193 [details, diff]
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.

[Comment 4 Carter Smithhart 2004-08-10 22:09:16 UTC]

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.

[Comment 5 kfm 2004-08-17 09:22:43 UTC]

> 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.

[Comment 6 kfm 2004-08-17 09:49:00 UTC]

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 *

[Comment 7 kfm 2004-08-17 09:50:02 UTC]

Oops, wrong bug - meant that comment for bug 51825 ... sorry.

[Comment 8 Jacob Joseph 2004-09-10 06:33:46 UTC]

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

[Comment 9 Heinrich Wendel (RETIRED) 2004-09-11 13:43:00 UTC]

*** Bug 58562 has been marked as a duplicate of this bug. ***

[Comment 10 Heinrich Wendel (RETIRED) 2004-09-11 14:07:44 UTC]

finally applied in zope-2.7.2-r1

[Comment 11 Jim Washington 2004-09-19 05:05:06 UTC]

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.

[Comment 12 Jesse Adelman 2004-09-19 16:11:29 UTC]

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... :(

[Comment 13 Jodok Batlogg (RETIRED) 2004-09-20 04:19:32 UTC]

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.