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