On Fri, Mar 21, 2003 at 10:15:01AM -0000, Jaroslav Lukesh wrote:

: Odesílatel: Jim Penny <jpenny@universal-fasteners.com> : Localfs objects have to be readable (at least) by the userid that zope : is running as. Zope should not be run as root, for a variety of good : reasons. Presumably your users own their own files, and in a modern : system, are proably in individual groups.

Another solution - what about samba server at local machine and smbfs mounted to the same machine?

localfs_user1 --> smbfs_mountedfolder_user1 --> /home/user1 localfs_user2 --> smbfs_mountedfolder_user2 --> /home/user2 etc...

Mounting like (single line):

mount -t smbfs -o uid=xxx,gid=xxx,username=user1,password=ffffff //localhost/mountpointuser1 /zope_localfs/user1

You only need to hide this file from reading at all, allow executing only. Rights like --x--x--x root root

I am unclear what you mean by this file. Are you talking about the mount script here? Or are you talking about /zope_localfs/user1?

I was used years ago this similar solution for multiple thin dosemu clients.

JL.

But, presumably the uid or gid has to be the same for all users, that is, it has to be the uid or gid that zope itself is running as. So, you are allowing zope, or anyone who has access to that userid to do whatever they will to the user directories! That is, the zope userid becomes a full proxy for each actual userid mounted using this technique. We have fully bypassed normal filesystem security again; in a worse way than a suid root agent, because we have nothing responsible for enforcing the policy, nothing can check that the policy is being followed. There is nothing wrong with the idea of using zope to access home directories, provided you are willing to live with the consequences. But you are making your life more interesting in many ways. Any way that you do this, you have a one-many map of zope userid to actual userid. That is, you are, by necessity, allowing a single userid to proxy for many userids. This is OK! But you have to be very sure that you trust all the software in the chain. That means zope, any interface software that you write, any portions of python that are used, and any other agents that are used to validate each access attempt. It also means that you have to trust your users and their password protection habits. To me, this is an uncomfortably long chain of trust - I especially worry about my own mistakes, which are less likely to receive "many eyeballs". None the less, if I were doing this, I would talk first to my users and get an acceptible security policy. Then, I would definitely write my own SUID root program that did any file retrieval and writing, and that attempted to enforce that policy. The difficulty with this is that full Unix semantics are a bit tricky, and this might make the SUID root program more complicated than I would like. If I were doing this, I would probably make my users do something proactive; like making them put anything that they wanted access to into a /home/user1/visible_via_zope directory. Then "best effort" security is much more palatable. Jim Penny

_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )