[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: a subtle(?) tar extraction permission problem



On Sat, 26 Jun 2004, Cameron Simpson wrote:

On 17:34 25 Jun 2004, Robert P. J. Day <rpjday mindspring com> wrote:
|   say i have a directory structure a/b/c/{f1,f2,f3,...}.  for access
| reasons, i decide to change the permissions on the "c" directory,
| perhaps changing the owner/group, and definitely changing the perms to
| include "setgid".
|   later, i get a tarball with contents a/b/c/{something}.  i found out
| that if i extract that tarball while root, and the effect is to add or
| delete files under the "c" directory, the permissions on "c" revert
| back to default values.  how annoying.

I think you'll find the tarball also has "a/b/c" in it too.

sure, but the attributes of *those* directories don't get changed when i do the extraction.


|   apparently, as long as what i'm extracting is already in that
| directory (so that the directory entries themselves don't change), i'm
| safe.  but if the extraction changes the directory contents
| themselves, i get the owner/group/perms resetting on "c", which i'd
| *really* like to avoid.
|
|   i've perused the tar options, and i don't see anything that says,
| "don't mess with existing options on existing directories."  is there
| a standard approach to handle this?

1: Don't extract as root?

not an option. a single package/tarball might want to put files/dirs in various places, owned by various accounts.


2: Note perms, extract, fix perms.

ouch. that would work, but it would definitely be a bit messy.


3: Extract only the files - avoid the directories.

tempting, but i'm wondering what would happen if the tarball has a directory that doesn't exist yet. it will have to be created, of course, at which point i'd have to take care of setting its original
attributes.


  A tar file has entries for the dirs, which is of course where the perms are.
  Don't as for them:

tar xvf tarfile a/b/c/f1 a/b/c/f2 ...

  You could do this algorithmicly by doing a table of contents,
  sucking out the filenames, then doing the extract.

again, i can't just assume that all of the directories in the tarball already exist on the system. dang. i was really after the hypothetical tar option "do *not* screw with the attributes of existing objects." i don't think i'm going to find it.


rday



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]