I’m not managing to reproduce it with that either.
True.
Probably not privleap, as privleap doesn’t use /tmp for anything unless put into a special test mode (which is only applicable when a special “regression testing mode” option is passed, not something that should ever occur “in the wild”). I wouldn’t really expect sudo to use $TMP, $TMPDIR, or similar (it looks like it may use /tmp but that shouldn’t cause this issue). I also grepped through both Whonix’s and Kicksecure’s package code for the string /tmp/user and didn’t find explicit use of the path in a context that would cause this issue. So it seems like something must be picking up TMPDIR and doing the wrong thing with it. I don’t think it could be a privleap action though since privleap intentionally does not allow the caller to dictate the callee’s environment, thus I don’t think TMP or TMPDIR could be “leaking” there.
edit: Would it be useful if I wrote a C program that used fanotify to try to trace what processes were modifying things under /tmp and wrote that information to a log file? That way you could reproduce the issue on your end, then look at the log to determine what process was at fault.