Chris McDonough wrote:
> 
> Bill Anderson wrote:
> > He seemed to be mostly griping about files that were wide open (777). On
> > 2.2.0b4 the only ones I get are:
> > lrwxrwxrwx    1 root     root 13 Jul 11 01:36 lib/python/ZEO/cPickle.so
> > -> ../cPickle.so
> > lrwxrwxrwx    1 root     root 13 Jul 11 01:36 lib/python/ZServer ->
> > ../../ZServer
> > srwxrwxrwx    1 root     root 0 Jul 11 02:08 var/pcgi.soc
> >
> > Notes:
> > o All but one of these are symbolic links.
> >   No way around 777 on them.
> >   No cause for alarm on them either.
> > o The two symlinks are from ZEO, and thus would
> >   not be in a default tarball.>
> > Now, I do *nix security for a living, and I don't have any issues with
> > these few, unexposed 777's. I'd be interested to hear what the concerns,
> > and how to avoid them are.
> 
> The other file (pcgi.soc) is a unix domain socket...  it gets created
> when you run "python w_pcgi" as a Zope install command from the source
> distribution.  I'm not sure of the danger of having this get created
> 777.  It might be worthwhile to look into what could be done to it.

Well, other than zope not responding over pcgi if it isn't 777?
I just tried this out of curiousity. No response through pcgi.

Bill


-- 
"Linux: the operating system with a CLUE...
Command Line User Environment".

seen in a posting on comp.software.testing

_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to