Re: [Bug-tar] tar 1.23 Solaris regression

[Eric Blake]

On 08/02/2010 12:21 PM, David Bartley wrote:
>> Problem is that users are expecting that their scripts (in our case info
>> script which is defined with option -F) is run with the same set of
>> privileges as tar program. In this case it's expected that script will
>> execute program for CD burning (which requires some additional privileges).

Interesting use case.

>> +  priv_set_restore_linkdir();
>> +
>>   execv (argv[0], argv);

Yes, that would fix it for any child process to have the same additional
privileges as the parent of tar, even though tar itself (intentionally)
does not want those privileges.

>> But First I'm not sure what is the reason for avoiding PRIV_SYS_LINKDIR
>> privilege. And if this is really necassary it should be probably restored
>> for every other program execution in src/system.c.

Your argument makes sense.  The dropped privileges are also used in
coreutils, such as in rm(1) and mv(1), but there, those programs have no
child processes to worry about.  But since tar does have the likelihood
of creating children, yes, it should play nicely and restore privileges
before exec()ing.

> I think the reason was to make sure that unlink on directories didn't
> work, avoiding a stat call to check if the target was a directory.

Not only that, but to avoid _hosing_ your file system if it calls
unlink() on what it thought was a file but in reality was a non-empty
directory slipped into its place at the last minute by an attacker.
That is, the inherent race between stat()ing a file and unlink()ing it
can lead to some serious messes that fsck will just punt on; and the
best way to avoid it is to ensure that unlink() atomically fails on
directories, by (temporarily) giving up that extra privilege.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature