From kragen@dnaco.net Sat Sep 26 12:38:17 1998 Date: Sat, 26 Sep 1998 12:38:16 -0400 (EDT) From: Kragen To: der Mouse Subject: Re: tar "features" In-Reply-To: <199809261623.MAA12210@Twig.Rodents.Montreal.QC.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: On Sat, 26 Sep 1998, der Mouse wrote: > >>>> * This code is full of potential races, > >>> I can't count the number of tar files I've extracted that had > >>> world-writable directories in them. > >> The races the comment is referring to are specifically races in the > >> checking code. [...] There undoubtedly are plenty of other races in > >> tar, though I do try to minimize them (for example, extracted > >> directories are mode 700 until it's done with them, whereupon it > >> chmod()s them to their in-archive mode. (This breaks certain > >> unusual tarfiles, but such tarfiles are usually no better with other > >> tars and often much worse.)) > > GNU tar does not do this. It creates them with the mode the tarfile > > specifies. However, it doesn't force your umask to 0, so the mode is > > filtered through your umask. But yes, that was the race I was > > thinking about. > > > What kind of unusual tarfiles does this break? > > r-xr-xr-x ./foo/ > rwxr-xr-x ./foo/file.c It sounds like this would work properly with your method, though -- create the dir as 0700, then chmod it later. > >> Of course, this does nothing about a directory that's > >> world-writeable in the tarfile; it'll come out world-writeable when > >> tar is done with it. [...a pseudo-umask argument...] > > Or you could use the real umask. That's what GNU tar and SunOS 4 tar > > do by default. > > Well, actually, everything uses the real umask unless you specify p. > tar does umask(0) at startup and saves the return value; if you > specified p, it uses that original umask it got when setting modes. GNU tar uses said original umask by calling umask() with it as an argument. Maybe that's what you meant -- or are you referring to mkdir(path, mode_from_tarfile & ~stored_umask); ? > It's true I was insufficiently precise in what I said above; if you > don't specify p and your umask includes the 002 bit, the directory > won't come out world-writeable regardless of whether the 002 bit is set > in the tarfile. Righto. > >> I don't want to kvetch about > >> ./foo -> ./bar/foo-dir > >> ./foo/datafile > > > Can this ever happen in a legitimate tarfile? > > As far as I know, only in the way you found: "tar cvf foo.tar ./foo > ./foo/datafile". More likely, perhaps, is for the ./foo symlink to > already exist. More than once have I untarred a file in a directory not created for that specific tar file, because the GNU (and others') convention is for all the files in the tar file to be in a single directory. So your scenario is not unlikely. > > I have been unsuccessful in getting GNU tar or SunOS tar to produce > > such an archive in a way that could reasonably be accidental. > > I'm not convinced the way you found couldn't be accidental - or perhaps > what I mean is not "accidental" but "non-malicious". OK. But what do you think about the point below? If you simply refuse to extract files into directories that are symlinks, you won't lose any legitimate files. > > Given that, if the file is in the to-be-extracted-into tree, it will > > be extracted anyway, it seems dangerous to allow this. > > It would be reasonable to have an option that refuses to destroy any > existing on-disk object for any reason. I don't think I have one at > present, but it would be a Good Thing to add. GNU tar has one -- I think IRIX tar does, too, from the recent BUGTRAQ message on it. IMHO, it should be the default. Tradition disagrees with me, but I don't think silent destruction should be the default. > > Code that tries to duplicate the OS's methods for determining where a > > particular filename points scares me. > > I'm not thrilled by it either, but I couldn't see any third alternative > but to give up on the j key altogether. What I've got is certainly a > lot better than nothing, I figure. :-) Agreed. > If chroot(2) were usable by > ordinary users, I could chroot to the extract-to directory and blow off > all the checking...except that that would make it difficult to do > things like open the next archive for reading. :-( Hmm. We need jails for things like this. Kragen -- Kragen Sitaker The sages do not believe that making no mistakes is a blessing. They believe, rather, that the great virtue of man lies in his ability to correct his mistakes and continually make a new man of himself. -- Wang Yang-Ming