[BUG] file.symlink backupname operation can copy remote contents to local disk

[nicholasmhughes]

Description
file.symlink when run with the backupname parameter, will attempt to copy an obstructing directory that is an NFS mountpoint as well. This has the side effect of filling up the local disk on the node. The cause is from file.symlink using the file.move execution module function to rename to the backupname target, which calls shutil.move under the covers. The shutil.move code attempts an os.rename and then falls back on a "copy then unlink" approach if an exception is thrown.

Steps to Reproduce the behavior
Mount an NFS directory, and then create a file.symlink state with backupname set which attempts to create a symlink with the same name as the mount point.

Expected behavior
Probably best to error in this situation so an administrator can take action.

Versions Report

salt --versions-report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
          Salt: 3005+0na.aadaf0b
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: Not Installed
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.2
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.4
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: 2.6.1
  pycryptodome: 3.15.0
        pygit2: Not Installed
        Python: 3.7.3 (default, Jan 22 2021, 20:04:44)
  python-gnupg: Not Installed
        PyYAML: 6.0
         PyZMQ: 24.0.1
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.4
 
System Versions:
          dist: debian 10 buster
        locale: UTF-8
       machine: x86_64
       release: 4.19.0-21-amd64
        system: Linux
       version: Debian GNU/Linux 10 buster