Chris McDonough wrote:
>
> Using gnutar, untarring as the root user preserves ownership on
> expansion by default. Not sure if FreeBSD uses gnutar (I imagine not),
> but this is the case with gnutar under Linux. I think this is what
> happened to him... he said he could not use the RPM release and was
> working with the source distribution, so I don't think the problem is
> with the RPM.
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.
Zope is actually one of the two places I avoid the RPMs (The other being
Kernel RPMs), adn always stick to source, so I can't vouch for the
permissions of files in the RPM
As I read his post, btw, it looked like he avoided the RPMs dues to the
problems, and was looking for source.
I have a copy of the 2.1.6 source; I'll look at that tonight for
permissions.
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 )