Hello Paul, On Thu, Oct 30, 2025 at 11:02:49AM -0600, Paul Eggert wrote: > On 10/30/25 08:00, Petr Sumbera wrote: > > > > Is there any progress with this please? > > Still working on it. The patch you sent fixes that test case, but it doesn't > fix all the attacks and it's too slow and leaks memory. We need something > better.
I looked at the option of using openat2 with RESOLVE_BENEATH in tar. There are more operations that tar needs to perform on a file/directory besised opening it and writing to it and they need to be protected the same way as writing is: chmod, chown, etc. As I mentioned on bug-gnulib ( https://lists.gnu.org/archive/html/bug-gnulib/2025-10/msg00159.html ), one can do that by always using openat2 first and then using fchmod / fchown / etc. on the descriptor instead of chmod / chown. I see that in src/extract.c these operation are done inside wrapper functions (fd_chown etc.) using a pair of arguments: (int fd, char const *file). When fd can be used, fchown() etc. is called on the fd, and if not, fchownat() is done on the file argument (pathname). This was introduced in commits 59146768e and ea964cce8, but to me it is not clear why to use two ways of setting (getting) the attributes. Would it work if the caller (set_stat()) always opened the file provided and passed down just the fd, instead of using both the file name and the fd? Is there a platform which has fchownat() but not fchown()? Having only one path (e.g. fchown()) in the wrappers (e.g. in fd_chown()) would simplify the refactor to use openat2. What do you think? Best regards, Pavel
