UNZIP does not honor default protection ACL (a very old version does)

[EdgarZamora_1]

Hoping Mr. Schweda can give me some insight on this problem...

A very old version of UNZIP honored the default protection ACL on the default directory. I installed a newer version and it doesn't seem to honor the ACL anymore. This behavior may have changed a while back (not just in the current version) since the old version we were running was from 1994.

Attached is a log file of my experiment. I even changed the default protection ACL just to make sure the old version was really using the ACL and it did. The new version seems to ignore it. Please let me know if I'm missing something completely. I'm known to do that.

[Steven Schweda]

> UnZip: Zipfile Extract v5.0 of 21 August 1992; [...]

Yow. Was I even _born_ in 1992? (I suppose
so, but I wasn't looking at Info-ZIP code
until about '04. I don't have anything older
than 5.51 around here.)

alp $ unzip6l -h
[...]
-X restore owner/ACL protection info -V retain VMS version numbers
[...]

By default, UnZip (6.0) does not restore
owner or ACL data. Perhaps a seriously old
version did. If "unzip -X" fails to satisfy,
then please re-complain.

[Steven Schweda]

Perhaps the real complaint is now sinking
into my (feeble) brain.

I don't know what the old one did, but when a
modern UnZip extracts a file, it will create
the thing, and then set its protections
according to the archived protection info.
If the OS doesn't interfere, then I know of
nothing in the UnZip code which would care
what the local directory ACL might be.

As I was just explaining to an HP-UX user, we
have had some discussion recently about
adding some UnZip option(s) to allow better
permission/protection control when extracting
files, but so far it's only talk. "-X" does
allow a little control, but I know of no way
to stop UnZip from trying to restore the
original protections on an extracted file.

And, if it's now better at restoring those
original protections, then this must be an
improvement, no?

[EdgarZamora_1]

I did test the -X switch and on both the old UnZip and new UnZip the results were the same whether I used -X or not. The old version uses the OS security settings, the new version applies the security settings from the zipped file. -X would seem to be the default behavior on the modern UnZip. Is there a way to negate this?

Thank you for your explanation thus far.

[Steven Schweda · Accepted solution]

> The old version uses the OS security
> settings, the new version applies the
> security settings from the zipped file.

Perhaps that 1992 UnZip didn't know how to
set the protection on an extracted file. Or,
if you're using a newer Zip (on VMS, with
"-V"), then the very old UnZip may understand
only the old "IM" extra field, not the modern
(1997?) "PK" extra field, used to store the
VMS attributes. (I don't see enough "zip -v"
info to know what made these archives.)

> -X would seem to be the default behavior on
> the modern UnZip.

Not exactly. With "-X", UnZip tries to
restore ownership and ACLs. By default, it
_always_ tries to restore the original SOGW
protections.

> Is there a way to negate this?

Not in UnZip 6.0. If you'd like to try
living dangerously, you could slap these onto
an UnZip 6.0 source kit:

http://antinode.info/ftp/info-zip/unzip60/minusx/unzip.c
http://antinode.info/ftp/info-zip/unzip60/minusx/unzvers.h
http://antinode.info/ftp/info-zip/unzip60/minusx/vms/vms.c

Re-build, and then use "--X" to inhibit the
setting of any original protection values.

Default: Restore SOGW protections.
-X: Restore SOGW protections, owner, ACLs.
--X: Restore no protections.

These changes are unofficial, not well
tested, VMS-only, and not at all documented,
and I will deny everything under oath.

If anything like this were to get into the
next UnZip version, then I'd expect different
(better) command-line options, perhaps with
separate control over ownership.

[Willem Grooters]

Amongst other things I like about ZIP/UNZIP is platform-independency. The ability to handle platform speciialities in some way is (at least for me) a requirement. If my target system cannot handle ACL's that are stored on the source system, it renders the zipfile unusable.
I agree though, that handling should be consistent, or otherwise be documented.

[EdgarZamora_1]

Steven, I built a beta UnZip with those source code changes you provided and...

...you're my hero!!!

Worked like a charm! I'll be doing more testing but it looks great so far.

Attached is the log of my test.

Thank you for your clarification on the "-X" and for the "--X" changes.

[Steven Schweda]

> [...] If my target system cannot handle
> ACL's that are stored on the source system,
> it renders the zipfile unusable. [...]

So far, I believe that all ACL data are
archived in system-specific extra fields, so
UnZip will never try to use a foreign ACL.
(It's very good at ignoring mysterious extra
fields.)

There is some hope for a cross-UNIX(-like)
ACL storage scheme, but I'd expect ACL
restoration to remain optional and
non-default.

> ...you're my hero!!!

So, you'll be using DELETE /ERASE on that
fossilized UnZip 5.0?

> [...] more testing [...]

Good idea. Wake me when it catches fire.
I've restarted the feature discussion among
the Info-ZIP folks, so it's possible that
something similar will appear in a future
real UnZip kit. (Hold your breath.)
Annoyingly, there's corresponding code
(chmod()/chown(), or whatever) in other
system-specific modules, too, so, even
ignoring the command-line complications, it's
not a trivial change to make properly.