[Bug-tar] Re: Permissions in tar archives

[Matt McCutchen]

Right now, in "--no-same-permissions" mode, tar opens the file supplying
the 9-bit mode from the archive and lets the umask or default ACL
subtract bits from that.  In "--same-permissions" mode, tar does this
and then "chmod"s the file so all 12 of its mode bits match those in the
archive.

The current "--no-same-permissions" mode has the advantage of preserving
executability (usually) while not doing anything insecure from the
perspective of the carefully-chosen umask or default ACL, but my
proposed mode of ignoring archive permissions except to determine
executability (which is not offered now) tends to be more useful.

I asked a random Linux guru I knew about tar and permissions and here's
what he said:
(21:44:24) mattmccutchen: Kevin?
(21:44:35) mattmccutchen: Could I have your opinion about something
Linux-related?
(21:44:50) kepreon: ok
(21:45:10) mattmccutchen: Do you happen to know what "tar" does to
permissions when you extract an archive with no options?
(21:45:34) mattmccutchen: And what do you think should happen?
(21:46:35) mattmccutchen: I don't mean look it up; I was just trying to
find out whether you might have any preconceptions.
(21:47:05) kepreon: I think it uses the permissions of the files from
when it was packaged
(21:47:16) mattmccutchen: What do you think should happen?
(21:47:27) mattmccutchen: That, or something else?
(21:47:54) kepreon: Well, it would make more sense if it was set to the
default permissions for the creation of a file by the same person...

Let me ask for another change to tar: let the "--mode" option specify
permissions for extracted files.  "--mode" can be given zero or more
comma-separated chmod(1)-style commands followed by either "umask" or
"verbatim".  tar starts with the permissions in the archive and applies
all the chmod(1) commands.  If the "--mode" ends in "umask", tar passes
9 bits of the resulting mode as the third argument to "open", allowing
the umask or the default ACL to take effect; if it ends in "verbatim",
tar follows this with an explicit "chmod" to set the 12-bit mode.  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"?  If so, we can use
"--owner-same" instead of "--owner=same", and so forth.)

Then, all the "--(no-)?same-.*" options can be written in terms of the
improved "--mode", "--owner", and "--group" options:
        --no-same-permissions: --mode=umask
        --same-permissions:    --mode=verbatim
        --no-same-owner:       --owner=me --group=me
        --same-owner:          --owner=same --group=same
        My proposed --no-same-permissions:
                               --mode=a=rwX,umask

The name "--no-same-permissions" is very vague; "--same-permissions"
doesn't have any obvious opposite.  But all the other names I can think
of that describe this behavior adequately are way too long.  So let me
suggest that "--no-same-permissions" be deprecated in favor of the pithy
"--mode=umask".  Neither can I think of a good short name for
"--mode=ugo=rwX,umask"; does anyone have an idea?

Source tarballs generally come with a few executable files, like
"configure", "missing", and "mkinstalldirs".  Preserving executability
is probably desired more often than creating everything but directories
nonexecutable.  Chris, if you want the latter behavior, you could use
"--mode=a=rw,a+X,umask".  Remember, chmod(1)'s X means "execute
permission if the file is a directory or someone already has it".  The
"a=rw" gives everyone r/w and kills any existing execute permissions so
that the "a+X" that follows only takes effect for directories.  The
analogous "chmod -R p-x,p+X ..." will do this to existing trees of files
if you replace "p" by an appropriate subset of "ugo".  ("find ... -not
-type d -exec chmod a-x {} \;" also works but is less elegant.)

-- 
Matt

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

On Sat, 2005-07-16 at 23:49 -0400, Chris Mulligan wrote: 
> Interesting. Have you received any response yet? I nearly guarantee you 
> that this issue has been brought up several times and has a, shall we 
> say, fiery past. Not that you shouldn't have sent the email, of course. 
> As for your thoughts, it makes sense. I don't use ACLs at all, and 
> haven't encountered your problem often, but I can see the logic. What, 
> exactly, was the problem with --no-same-XXX? (aside from your memory?). 
> Dysfunction means it results in what? I'm assuming it truly ignores 
> executability? I would vote that it ignores exec for everything EXCEPT 
> directories. Many times you'll encounter entire directories at 777 out 
> of laziness and would want that stripped.
> 
> That said, bravo to you! You're the key to FOSS :)