On Thu, Jul 21, 2011 at 10:01 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
> On Thu, Jul 21, 2011 at 21:31, Andy Canfield <andy.canfield_at_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
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.)
Received on 2011-07-22 04:24:29 CEST