在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用戶運行普通服務的原則，個人覺得還是非常應該堅持的，事實上形成了沙箱保護。而且，如果不是這次執拗的堅持必須以普通用戶運行，則不會發現此不同的寶貝和明白以前之陋:)