The trouble with symbolic links

Before starting the job, move the complete user space folder into another one where the user cannot reach it, check for still open file handles of the user, then do your job without fear of toctou by evil users and at the end move the folder back in place where the user can work on it.

Another opportunity would be to temporarily remove login of the user, sigstop all of his processes and disable his cron/at jobs, let the privileged task be done and afterwards sigcont the processes again.

Similar for shares, disable the user, check no currect connection is alive, do the job and enable the user again. Or just completely shutdown samba while the higher privileged job runs.

Those who wants the user to be able to work while the higher privileged job is ongoing, would just add more insecurities that reside within the programs that work on the files but don't expect the file to be changed while reading or maybe even mmapping it. At least whatever the higher privileged task does with the data, cannot be assumed to be consistent.

If you let the user change anything inside his userspace while higher privileged tasks are running, the user might just add data to the end of a file currently read by root and punch the data at the beginning so that he does not exceed his quota. The process reading the file (into / partition?) could end uptrying to read like 16TiB before the user has to try using collapse instead of punch to see if the root cronjob continues to read even more of the file.
(Fortunately the user cannot directly see the offset of the root processes filehandle, so he must rather guess where the other process currently is, to do this type of attack)
Is this attack vector now caused by PUNCH or COLLAPSE? Do we have to remove them just for beeing able to run root commands on userspace data while the user is able to work on it as is suggested here with symlinks?