installation security best practice question
HI i am installing zope in on linux fedora core 3 however i am having problems when setting up the permissions. Currently i am installing zope as root and then logging in as a user and making an instance. When i go to run the zope instance as the user its says i do not have the permissions to run the files. If i change the permissions on the zope folder so that everyone has all permissions then it works however this isnt a great securtiy option Does anyone have any ideas on how to sort this one out Thanks -- View this message in context: http://www.nabble.com/installation-security-best-practice-question-t1278137.... Sent from the Zope - General forum at Nabble.com.
Currently i am installing zope as root and then logging in as a user and making an instance. When i go to run the zope instance as the user its says i do not have the permissions to run the files.
If i change the permissions on the zope folder so that everyone has all permissions then it works however this isnt a great securtiy option
Does anyone have any ideas on how to sort this one out
The best way to install and run Zope is to have a dedicated user account and install and run it as that user. Most everything else will lead to problems and frustration. jens
En/na Jens Vagelpohl ha escrit:
The best way to install and run Zope is to have a dedicated user account and install and run it as that user. Most everything else will lead to problems and frustration.
Only because the zope-2.8.6 tarball has wrong permissions. It worked before, it will work once you fix the permission on the installed zope. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
On 14 Mar 2006, at 14:09, Luca Olivetti wrote:
En/na Jens Vagelpohl ha escrit:
The best way to install and run Zope is to have a dedicated user account and install and run it as that user. Most everything else will lead to problems and frustration.
Only because the zope-2.8.6 tarball has wrong permissions. It worked before, it will work once you fix the permission on the installed zope.
The advice has nothing to do with Zope 2.8.6 or any other tarball. Trying to be overly clever and not using a dedicated account for both installation and running your Zope doesn't add much security, it only adds complication. Unless you install software that lets users write to the file system through the web people cannot get to the filesystem. jens
En/na Jens Vagelpohl ha escrit:
On 14 Mar 2006, at 14:09, Luca Olivetti wrote:
En/na Jens Vagelpohl ha escrit:
The best way to install and run Zope is to have a dedicated user account and install and run it as that user. Most everything else will lead to problems and frustration.
Only because the zope-2.8.6 tarball has wrong permissions. It worked before, it will work once you fix the permission on the installed zope.
The advice has nothing to do with Zope 2.8.6 or any other tarball. Trying to be overly clever and not using a dedicated account for both installation and running your Zope doesn't add much security, it only adds complication.
But one zope instance doesn't need write access to zope itself, only to the instance directory. It needs read access though, and it's not setup this way by the latest zope, so I think that the problem of the OP come from this change in permissions in the tarball.
Unless you install software that lets users write to the file system through the web people cannot get to the filesystem.
I usually install zope as root to /usr/local, then setup (or actually use the already set up) instances for two different users, one for production and the other for testing, so I don't want to install as the same user, since I don't want to duplicate the zope installation, only the instance, and that should be possible (in fact it has been until now) without compromising security. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
On 14 Mar 2006, at 15:13, Luca Olivetti wrote:
Unless you install software that lets users write to the file system through the web people cannot get to the filesystem.
I usually install zope as root to /usr/local, then setup (or actually use the already set up) instances for two different users, one for production and the other for testing, so I don't want to install as the same user, since I don't want to duplicate the zope installation, only the instance, and that should be possible (in fact it has been until now) without compromising security.
My point was that the "security" you speak of is illusory. You don't win anything. jens
En/na Jens Vagelpohl ha escrit:
On 14 Mar 2006, at 15:13, Luca Olivetti wrote:
[...]
the same user, since I don't want to duplicate the zope installation, only the instance, and that should be possible (in fact it has been until now) without compromising security.
My point was that the "security" you speak of is illusory. You don't win anything.
I win 58M of space (since I install zope only once), and I lose nothing (unless you're saying that the product of "./configure; make; make install" is a security problem if world readable). Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luca Olivetti wrote:
En/na Jens Vagelpohl ha escrit:
On 14 Mar 2006, at 15:13, Luca Olivetti wrote:
[...]
the same user, since I don't want to duplicate the zope installation, only the instance, and that should be possible (in fact it has been until now) without compromising security.
My point was that the "security" you speak of is illusory. You don't win anything.
I win 58M of space (since I install zope only once), and I lose nothing (unless you're saying that the product of "./configure; make; make install" is a security problem if world readable).
Note that I think the original poster must not have done 'make install', but rather was using an inplace build directly from the unpacked tarball: the install process would have fixed up the permissions otherwise. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFvMW+gerLs4ltQ4RAj+3AJ9tLsowf2algCaDuBmn5NUQUQgJegCgkEnO 4IXSI8Q4ORBMNcJy9j6SPXc= =HTIJ -----END PGP SIGNATURE-----
En/na Tres Seaver ha escrit:
Note that I think the original poster must not have done 'make install', but rather was using an inplace build directly from the unpacked tarball: the install process would have fixed up the permissions otherwise.
No, it doesn't (with 2.8.6) Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Luca Olivetti wrote:
En/na Tres Seaver ha escrit:
Note that I think the original poster must not have done 'make install', but rather was using an inplace build directly from the unpacked tarball: the install process would have fixed up the permissions otherwise.
No, it doesn't (with 2.8.6)
Bye
OK, after some investigation: the issue is not the weird UID/GID on the files (which get preserved when unpacking the tarball as root); the issue is that the person making the file had their umask set to harshly (0077, likely), which means that the files are not readable by anyone but the owner. A workaround is to change the readability after unpacking the tarball, e.g.: $ chmod -R a+r . Andreas, can you confirm? Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEGDoC+gerLs4ltQ4RAt1tAJ9OkVihsS2Nvgt4hDv+FKtLP5oReQCferMr Nnoc8K10mVYf9xI3h0BHezk= =x69l -----END PGP SIGNATURE-----
--On 15. März 2006 11:00:03 -0500 Tres Seaver <tseaver@palladion.com> wrote:
OK, after some investigation: the issue is not the weird UID/GID on the files (which get preserved when unpacking the tarball as root); the issue is that the person making the file had their umask set to harshly (0077, likely), which means that the files are not readable by anyone but the owner. A workaround is to change the readability after unpacking the tarball, e.g.:
$ chmod -R a+r .
Andreas, can you confirm?
ACK Usually I build the release on my Linux box where the umask is 0002 however 2.8.6/2.9.1 have been build during Pycon on my Powerbook where the umask is 0077. I recreated the archives and re-uploaded them just some minutes ago. Andreas
Hi
Currently i am installing zope as root and then logging in as a user and making an instance. When i go to run the zope instance as the user its says i do not have the permissions to run the files.
If i change the permissions on the zope folder so that everyone has all permissions then it works however this isnt a great securtiy option
Give your Zope Instance(s) one dedicated user (e.g. 'zope'), i.e. Change the owner of the whole Instance to this user and then you won't have any troubles with the standard permissions that are configured by mkzopeinstance.py If you start your Instance(s) as that above user then you can avoid running your Instance(s) as root. Not much magic involved there... Kind Regards Maik
I have tried this method i have made a zope instance as a dedicated user the owner of this file is that of the dedicated user. when i go to run zope as this user i get an error message saying that there is an error opening a file in the install directory ( not the zope instance) if i change the permssions on that file i get an error saying that there is an error opening another file (in the install directory). any ideas how i can avoid this. -- View this message in context: http://www.nabble.com/installation-security-best-practice-question-t1278137.... Sent from the Zope - General forum at Nabble.com.
On 14 Mar 2006, at 12:31, JulianRead wrote:
I have tried this method i have made a zope instance as a dedicated user the owner of this file is that of the dedicated user.
when i go to run zope as this user i get an error message saying that there is an error opening a file in the install directory ( not the zope instance) if i change the permssions on that file i get an error saying that there is an error opening another file (in the install directory).
any ideas how i can avoid this.
I repeat: *Install* and run with the same user. jens
Jens Vagelpohl <jens@...> writes:
I repeat: *Install* and run with the same user.
I second that, since it is probably easier for you to set up a new instance this way than to bug around with your existing Instance. ( a simple "chown -R zope /path/to/your/instance" should have worked to, but I guess something is borked in your instance - so you'd better start from zero with a fresh instance ) Kind Regards Maik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 JulianRead wrote:
I have tried this method i have made a zope instance as a dedicated user the owner of this file is that of the dedicated user.
when i go to run zope as this user i get an error message saying that there is an error opening a file in the install directory ( not the zope instance) if i change the permssions on that file i get an error saying that there is an error opening another file (in the install directory).
any ideas how i can avoid this.
The Zope user needs to be able to read every file under the install directory. Those files are "software", and should be safe to make world readable, e.g.: # chmod -R a+r /path/to/installed/zope The Zope user needs *write* access only into the 'var' and 'log' subdirectories of the instance, but must have read access to the whole instance. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFsjg+gerLs4ltQ4RAsUoAJ9KQgxtYKqMyTFwX6HeF2rYbGavvQCfcwGq SJPdrmowKRyb8dUNyCihCCo= =0RLo -----END PGP SIGNATURE-----
participants (6)
-
Andreas Jung -
Jens Vagelpohl -
JulianRead -
Luca Olivetti -
Maik Ihde -
Tres Seaver