Changing file ownership can only be done by root. Ordinary user_a simply cannot create a file owned by ordinary user_b, whether file creation is done by gzipping or by gunzipping. If you need to preserve ownership, unzip as root.
Disk images are just containers that emulate a disk. The DMG's contents are distinct from the DMG container. So you've probably only converted the container to read/write.
For example:
We can convert a DMG that contains an ISO to be read/write, but the ISO itself can only be read-only:
___________________ ___________________
| | | |
| Disk Image (r/o) | | Disk Image (r/w) |
| _______________ | | _______________ |
| | | | ==> | | | |
| | ISO9660 (r/o) | | | | ISO9660 (r/o) | |
| |_______________| | | |_______________| |
|___________________| |___________________|
You run into a similar problem with the hybrid filesystem images that many OS distributions are shipping these days.
Here's an excerpt from the hdiutil(1) man page section on Hybrid images:
The generated image can later be burned using burn, or converted to another read-only format with convert.
The generated filesystem is not intended for conversion to read-write, but can safely have its files copied to a read/write filesystem by ditto(8) or asr(8) (in file-copy mode).
So there's the work-around: Copy the files off and make another DMG.
Which, unfortunately, is probably what you were hoping to avoid.
By the way, you might find this command helpful to peek into the DMG's partitions:
hdiutil pmap your_file.dmg
Best Answer
Most .dmg files are read-only. A common workaround is to copy the contents of a mounted .dmg to a folder on your hard drive, and making your edits on that copy.
If for some reason that workaround won't work for you (not enough free disk space perhaps?), you can mount a read-only disk image with a "shadow file" to make it act writable. All writes are actually written to the shadow file instead of the original read-only .dmg, which is left untouched.