[Toybox] [BUG] tar cannot handle files in non-writable dirs

[Jesse Rosenstock]

On Mon, Sep 15, 2025 at 6:59 PM Rob Landley <rob at landley.net> wrote:
> The problem with tar is there's no direct relationship between different
> entries in the archive, it's all just a bunch of "put something at this
> path" nodes saved in order so creating a directory is unrelated to
> putting something in that directory, so it doesn't cache directory
> credentials. Each path is resolved separately for each node.

Could keeping a mapping of created directories to open fds be a solution?

> Changing the timestamp on files at paths didn't seem to have significant
> security concerns. Changing permissions kind of does. (The classic race
> condition where an inotify process does a mv of a file/directory out
> from under tar and swaps in something else. That's hard to test for
> cheaply, even the --restrict logic is just doing an xabspath and a
> string comparison, there's no obvious "I atomically opened a filehandle
> and then verify the filehandle goes to what I think" way to _eliminate_
> the race window, or at least I can't think of it right now without
> grubbing around in /proc. (I can read the filehandle's symlink in
> /proc/self/fd to get an abspath for a filehandle, but is there a syscall
> or fcntl() or something for it? Of course not...)

I don't quite see the problem.  Couldn't the evil inotify process do
the same thing after tar is done?

How do other tars handle this?  OpenBSD could be an interesting one to look at.