[Bug-tar] Re: Permissions in tar archives

[Matt McCutchen]

>> "--mode" can be given zero or more comma-separated chmod(1)-style
>> commands followed by either "umask" or "verbatim".
>
> I like the first idea, but the "umask"/"verbatim" thing should be a
> separate option.  This is to maintain consistency with other GNU
> utilities like mkdir and install, which use --mode with the same
> meaning as chmod.

OK.  I guess we could use the existing "--same-permissions" vs.
"--no-same-permissions" for "verbatim"/"umask" respectively.

>> It would be nice to also support "--owner" and "--group" options for
>> extraction, with the empty string or "same" indicating the owner or
>> group in the archive and "me" indicating the extractor.  (Do we have
>> to worry about real users called "me" and "same"?
>
>Yes.  I suggest using "/" to denote the owner or group in the archive,
>and the empty string to denote the owner or group of the extractor.
>This would be a pure extension to chmod's operand.  Also, we can
>follow chmod's lead and use : to separate the owner from the group, so
>that we don't need the --group option any more.  E.g.,
>
>       --owner=matt      Extract as owner matt.
>       --owner=matt:sys  Extract as owner matt, group sys
>       --owner=/:/       The default: extract owner/group from tar file.
                          ^ Only for root.
>       --owner=:         Same as --no-same-owner --no-same-group
                          ^ This is the default for everyone else.

"chown" instead of "chmod", I think.  Let's support all the same formats
as "chown" does:
        owner          Change only the owner.
        owner:         Change the owner and use his/her default group*.
             :group    Change only the group,
        owner:group    Change both.
Let's continue to support "--group" just to be nice.

* Some say "login group", but this was probably more accurate back in
the days of "newgrp" when processes didn't have supplementary groups.

The empty string clearly should mean "don't change anything", but where
are we starting?  The archive or the extractor?  With "--mode" we
started with the archive; I think we should do the same here.
Separately, the "--same-owner" vs. "--no-same-owner" and "--same-group"
vs. "--no-same-group" switches should determine whether the owner and
group calculated by this procedure actually take effect; if not, no
"chown" or "chgrp" is performed and the extractor's credentials
(generally) take effect.  This might seem bizarre, but it makes a
perfect analogy to "--mode".  "tar" could issue a warning if an
"--owner" or "--group" specification is being completely ignored due to
"--no-same-owner" or "--no-same-group" mode.

However, "--no-same-permissions" doesn't mean "completely ignore the
permissions in the archive except for executability".  So I think we
have a precedent to allow the group calculated by "--group" (or
"--owner") to take effect via an explicit "chgrp" call if
        (1) it exists on the system,
        (2) the extractor belongs to it, and
        (3) no BSD semantics or "setgid" bit would specify otherwise,
even if "--no-same-group" is set.  However, this rule would never apply
to the "root" group so that "dtar"-style archives can safely use this
group; this exception only matters if someone other than root is in the
root group (rare) or root's default group isn't root (rarer).  Tell me
whether you think this is a good idea or crazy.

In a previous message, I mentioned my tar wrapper program "dtar"; let me
elaborate.  I believe that almost all "tar" archives can be divided into
two categories:
        (1) Archives that contain only data and whose file security
            information is meaningless except for executability
        (2) Archives that contain useful file security information and
            will only be extracted on a system with an equivalent set of
            users and groups
I would call archives of the first kind "dtar" (data tar) archives and
those of the second kind "fstar" (filesystem tar) archives.  In place of
my request for a "--dtar" option, I'd like it if "tar" behaved specially
when invoked with the name "dtar" or "fstar" by implying these options:
        dtar: --mode=ugo=rwX --no-same-permissions --owner=0:0
              --no-same-owner --no-same-group
        fstar: --same-permissions --same-owner --same-group
As I mentioned before, "dtar -tv" should not list file security
information.  It could in fact merge executability into the file type
and show one of "-xdlcbps".  I guess "dtar --compare" should not compare
it either, although one could argue that "dtar --compare" should compare
it to the default security information for new files.

Still better would be if people started using the extensions ".d.tar"
and ".fs.tar" to more clearly identify the purpose of their archives.
This way they will be identified as tar archives by everyone but smart
file browsers and Web-server index generators could add a nice touch.  I
plan to start doing this myself.  But the underlying "tar" format would
still be compatible; it's just that ".d.tar" archives have all the
security information "root:root rw-rw-rw-" (or "rwxrwxrwx") and that
hardly any ".fs.tar" archives have this property.

> (Of course, someone would need to implement all this.  :-)

Designing is always the fun part.  :-D  I could try; I took a look at
some of tar's source code and it doesn't seem too terrible.

-- 
Matt

==================================================
Richard Matthew McCutchen, ``hashproduct''
E-mail: address@hidden
Web site: http://mysite.verizon.net/hashproduct/
==================================================