On Thu, Jul 21, 2011 at 10:01 PM, Andy Levy <andy.l...@gmail.com> wrote: > On Thu, Jul 21, 2011 at 21:31, Andy Canfield <andy.canfi...@pimco.mobi> wrote: >> I ran into a problem with a web site I am developing under Drupal; a problem >> related to user. And I suspect that the same problem arises witn Subversion. >> >> On my local copy of that site, sometimes the PHP code creates a directory >> and puts files into that directory. The directory had standard permissions >> - readable by all but writable only by owner. But that directory is owned by >> www-data because apache/PHP created the directory. >> >> But when I zip it up, upload it to the server in Hong Kong, and unzip it, >> all directories are owned by the user on the server who unzipped the >> directory. The permissions were preserved; still readable by all but >> writable only by the owner. But the owner was no longer the Apache user, it >> was the user who unzipped the directory. I had to invent two shell scripts; >> one to run on my computer finding all the directories owned by Apache on my >> machine, and the second run on the server making all those directories >> writable by all. > > Use tar to package your files for transport, and it'll preserve the > ownership & permissions when extracting, assuming you use tar > properly. > > http://www.gnu.org/software/automake/manual/tar/Attributes.html
Not unless he is the root user (to reset ownership of extracted files), the root user or a member of the groups (to reset groiup ownership), and the underlying filesystem permits such settings (which a FAT32, SSH on FUSE, or some other filesystems do not support). Please don't gloss over the necessary underlying architecture when giving an answer like that. For example, being able to extract files and set ownership to root" as a normal user would imply being able to extract "suid root" files as a normal file, meaning you could extract a file that is owned by root and runs as root and can therefore do *anything* without having other special privileges. This actually ties to Subversion security issues I've noticed in the past. People use Subversion for system configurations, source code and Apache setups and cron jobs and setup tools, that get run as root. Then they say "ohh, we trust the people we work with!!!" and "we have a firewall" and "if someone is inside our network, we have a lot bigger problems than this!!!" And they ignore security of configuration tools that can set passwords, install SSH keys, open firewalls, or simply "rsync /emptydir/ / --delete" and cause endless havoc. (I've had that last one happen in a badly written shell script by a developer who caught the consequences early, but almost wiped out databases on NFS shares.)
