奇异现象其实也很根本---谈centos部署jenkins运行脚本遭遇的Permission Deny问题

 在centos7中，用rpm方式安装了jenkins持续集成&交付的环境，按照安装后的默认配置值，运行jenkins服务，jenkins进程所使用的用户，非root用户，是特殊的jenkins普通用户。在个人使用jenkins job中，执行某些脚本访问文件或目录时，就遭遇了Permission Deny问题。

      出现此问题时，由于有些Linux使用上的经验，个人用which xCommand查看到底能否在jenkins运行脚本里面找到相关xCommand运行命令，以及用绝对路径执行xCommand均得到了失败的提示。其中，which xCommand提示no Command；直接执行xCommand提示Permission Deny。

   对此问题，肯定首先想到先看看网上有什么已有解决方法，搜索了下网上的解决办法，大多数博文建议修改jenkins服务默认使用的用户为root或者修改jenkins用户的归属组为root Group。

    以此简单粗暴的方法解决此问题，但这种解决办法实际上违背了jenkins rpm的设计初衷！rpm安装好服务后，在默认情况下需要限制jenkins服务运行在非root级别，做一个沙箱限制，避免影响它人。不过，根据网上粗浅的解决办法，我大致知道是因为用户权限问题，但是具体出现在什么地方呢？

    我们知道在Linux的世界里面，对于某个文件的访问权限(RWX)分为三大类别：拥有者、同组成员、其他人。所以，用ls -al absolutePath/xCommand的方法查看命令的权限设置。初看权限列表，也是诧异的很，xCommand限定了拥有者具有全权限，同组和其他人都具有读和执行的权利，即r_x权限。那么xCommand应该可以访问和执行的？但为什么会报错呢？

     不解很久，也很疑惑，索性去倒杯水，整理下思路。后突然间有了点灵感，何不试试分析下所涉及的PATH路径上所有环节的访问权限，都是兼容的呢？顺藤摸瓜，逐段分析PATH路径上的DIR访问权限，终于发现某段同组和其他人权限设置上缺少读和执行的权利，这就是其中原因了！

    Linux检查了全路径上是否可以访问和执行，某一环节的权限不兼容，即可导致which xCommand终止搜索命令(虽然在PATH环境变量里面也设定了那个目录)，和直接以绝对路径执行xCommand命令报Permission Deny的提示。

   从这次遭遇上，明白了以前所谓已经明白的RWX权限设置，实际上在经验和意识中还是很肤浅的。只有通过一次深度的互动接触，特别是有痛楚后突破的经历，才有深刻的理解！

   Linux上非root用户运行普通服务的原则，个人觉得还是非常应该坚持的，事实上形成了沙箱保护。而且，如果不是这次执拗的坚持必须以普通用户运行，则不会发现此不同的宝贝和明白以前之陋:)