Bugzilla Bug 59217

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

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

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.

Created an attachment (id=37193) [edit]
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.

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.

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

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 *

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

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

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

finally applied in zope-2.7.2-r1

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.

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

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.