When executing a method throught the web, we have seen the following error message...
Site Error An error was encountered while publishing this resource.
Error Type: IOError Error Value: [Errno 13] Permission denied: '<<<some directory path>>>/var/Data.fs.index.index_tmp'
which googling suggests is due to the protections of the var directory not having public write permissions set. My configuration vis a vis permissions is right out of the book drwxr-xr-t 2 root root 4096 Oct 27 17:39 var with zope running as a local user ( -u zope ). The question, then, is "What should the permissions on var be?".
Dennis Allison wrote:
which googling suggests is due to the protections of the var directory not having public write permissions set. My configuration vis a vis permissions is right out of the book
drwxr-xr-t 2 root root 4096 Oct 27 17:39 var
with zope running as a local user ( -u zope ).
The question, then, is "What should the permissions on var be?".
Whatever your system policy dicates it should be. What you have makes no sense though. Zope used to ship with a document detailing the proper ownership and permissions of the data directory, but that document was wildly incorrect (it describes something like what you have above). Unfortunately people seem all to happy to blindly follow instructions than to actually bother figuring out how unix filesystem permission really work. Step 1, is to make sure you're not running zope as root http://audible.transient.net/zope/#root Step 2, is to make a group for your zope instance, eg. "zope" Step 3, is to make a user for your zope instance, eg. "zope" with its primary group set to the group you've created in step 2 Step 4, is to set up the instance home, you should choose a partition intended for this kind of thing, on my systems I use /var/local/zope There are a bunch of silly default paths from here which I'll stick to only for the purposes of example, but don't feel tied to them. Consider this view of /var/local/zope: drwxr-xr-x 3 root staff 4096 Nov 1 14:32 . drwxrwsr-x 7 root staff 4096 Nov 4 01:07 .. drwxr-sr-x 2 root staff 4096 Aug 6 00:59 Extensions drwxr-sr-x 2 root staff 4096 Aug 6 00:59 Products drwxr-sr-x 2 root staff 4096 Sep 22 03:00 import drwxr-s--- 2 zope staff 4096 Oct 31 13:27 var This gives you a data directory ("var") that zope can write to, but keeps other users (apart from the superuser) out, unless they are part of the staff group (handy for admins to be able to debug stuff in there). If you're running zope as the "zope" user created earlier (directly, not via '-u' or other setuid misfeatures) this should give the process enough leeway to do what it needs to do with its data files and logs. Step 5, abandon all of the above and switch to zeo to get even further seperation, but I'll leave that for another discussion -- Jamie Heilman http://audible.transient.net/~jamie/
Jamie -- Thanks for the pointers. I followed the 2.6.2b3 instructions without thinking much about the protections on var. The z2.py startup routine shipped with the 2.6.2b3 version tries to enforce the requirements of the setup doc. My startup routine is a modification of z2.py and preserved the checks. )-: BTW, all Zope users should take a look at your site, http://audible.transient.net/zope/. On Wed, 5 Nov 2003, Jamie Heilman wrote:
Dennis Allison wrote:
which googling suggests is due to the protections of the var directory not having public write permissions set. My configuration vis a vis permissions is right out of the book
drwxr-xr-t 2 root root 4096 Oct 27 17:39 var
with zope running as a local user ( -u zope ).
The question, then, is "What should the permissions on var be?".
Whatever your system policy dicates it should be. What you have makes no sense though. Zope used to ship with a document detailing the proper ownership and permissions of the data directory, but that document was wildly incorrect (it describes something like what you have above). Unfortunately people seem all to happy to blindly follow instructions than to actually bother figuring out how unix filesystem permission really work.
Step 1, is to make sure you're not running zope as root http://audible.transient.net/zope/#root Step 2, is to make a group for your zope instance, eg. "zope" Step 3, is to make a user for your zope instance, eg. "zope" with its primary group set to the group you've created in step 2 Step 4, is to set up the instance home, you should choose a partition intended for this kind of thing, on my systems I use /var/local/zope
There are a bunch of silly default paths from here which I'll stick to only for the purposes of example, but don't feel tied to them.
Consider this view of /var/local/zope: drwxr-xr-x 3 root staff 4096 Nov 1 14:32 . drwxrwsr-x 7 root staff 4096 Nov 4 01:07 .. drwxr-sr-x 2 root staff 4096 Aug 6 00:59 Extensions drwxr-sr-x 2 root staff 4096 Aug 6 00:59 Products drwxr-sr-x 2 root staff 4096 Sep 22 03:00 import drwxr-s--- 2 zope staff 4096 Oct 31 13:27 var
This gives you a data directory ("var") that zope can write to, but keeps other users (apart from the superuser) out, unless they are part of the staff group (handy for admins to be able to debug stuff in there).
If you're running zope as the "zope" user created earlier (directly, not via '-u' or other setuid misfeatures) this should give the process enough leeway to do what it needs to do with its data files and logs. Step 5, abandon all of the above and switch to zeo to get even further seperation, but I'll leave that for another discussion
-- Jamie Heilman http://audible.transient.net/~jamie/
participants (2)
-
Dennis Allison -
Jamie Heilman