我们正在实施一项服务，需要访问驻留在不同服务器上的三个磁盘 。 我已经挂载了磁盘（2在Windows文件服务器，CIFS; 1在另一台Linux服务器上，NFS），脚本现在工作正常。
我的经理对“永久安装”不是很满意，并认为这是一个安全风险：如果服务器上的任何脚本受到攻击，则可以访问安装的磁盘。 他build议每个需要磁盘的脚本，在脚本开始时装载磁盘，并在脚本结尾处卸载它们。
我不是很喜欢这个想法，但我无法说服他。 我试过的一些论点：
有人可以告诉我，如果我是正确的，每次都要警惕这个挂载/卸载，或者如果我错了，它真的是要走的路 – 更具体地说：为什么？
对不起，但你是不对的。
问候
自动mountnetworking共享意味着将凭据存储在某个文件的某处， mount可以读取它们（在cifs文件系统的情况下，通过credentials=filename挂载选项） – 这不一定是个问题，但可能是一个安全问题，即使是攻击者到脚本。 将凭据存储在这样的文件中比直接将它们保存在脚本中更安全，因为这样当用户用ps或类似的方式search任务列表时，它们就不会出现在命令行中，但是对于你来说，这是非常重要的确保只有脚本可以读取文件。 您担心在这种情况下妥协服务器的用户没有什么不同 – 如果他们在服务器上运行时妥协，他们可能会有权访问这些共享。
安装和卸载共享的成本不应该太高 – 几秒钟（如果那样的话），除非您通过非常慢的高延迟连接与共享进行交stream，并且从安全angular度来看可能更好，因为您不是在不需要的情况下保持共享的安装（有可能使其他用户可以访问），另一端可以在脚本validation和断开连接时进行login（所以如果在另一端发现问题最后，跟踪在发生问题时可能访问的内容比较容易）。
尽pipe重叠的脚本执行，保持共享可以通过在某个位置（比如/var/run目录下的一个目录）随机删除一个文件（或者其他脚本调用不太可能被另一个脚本调用复制），然后删除该文件脚本的实际工作已经结束 – 比在最后检查运行umount之前没有其他文件在该目录中。 另一种方法是通过为每个脚本提供自己的挂载点来允许多个挂载到相同的共享 – 这样每个脚本将拥有自己的共享，不会干扰其他脚本，还可以为每个脚本提供自己的authentication凭据您可以select在另一侧以更细粒度的方式pipe理权限（也许某些脚本需要读取+写入权限，有些则只需要只读权限）。