PDA

Bekijk Volledige Versie : Re: GNU tar and the setuid bit



David Watson
09/08/05, 17:55
On Friday 05 Aug 2005 12:52 am, Imran Ghory wrote:
> If running as the root user tar restores the original permissions to
> extracted files, this includes the setuid bit. No warning is given to
> the user that this has happened.
>
> The default behaviour of tar under root is not to change ownership of
> the file to root. However owner information is extracted from the tar
> file, so a trivialy modified tar file can ensure the owner of the
> extracted files is the root user.
>
> This allows for the creation of arbitary setuid executable owned by
> the root user if the root user extracts the files from a malliciously
> crafted tar file.

With GNU tar (which you seem to be referring to), using --no-same-permissions
when extracting clears all of the setuid, setgid and sticky bits in addition
to subtracting the umask (undocumented behaviour, but logical enough). It's
advisable to use this along with -o when extracting random archives as root.
(Although as I've just noticed, -o alone will turn any setuid executable into
a setuid-root executable - now that *is* a bug!) Or of course, you could
extract them as someone else ;)

It looks as if they're planning to make --no-same-permissions the default for
root in future, but 'alias tar="tar --no-same-permissions"' does the trick
for now, if you don't mind breaking the old-style option syntax (-p reenables
the full permissions from the archive, of course).

(By the way, -o is broken in version 1.14 at least, but --no-same-owner
works.)

David Watson
09/08/05, 18:05
On Saturday 06 Aug 2005 4:22 pm, David Watson wrote:
> (By the way, -o is broken in version 1.14 at least, but --no-same-owner
> works.)

Sorry, I just noticed that that last comment was entirely misleading! In all
versions, using --no-same-owner without --no-same-permissions *will* cause
the setuid and setgid bits to be preserved even where the owner or group has
been changed to root (i.e. where a different UID or GID was specified in the
archive), as will using -o (in 1.15) without --no-same-permissions. The -o
option is 'broken' in 1.14 (and possibly in earlier versions) in that it
simply fails to enable the intended behaviour (in fact it enables the exact
opposite, being equivalent to --same-owner).