一種軟體包編譯平臺針對用戶設置權限的方法
2023-06-15 17:51:26 1
專利名稱：一種軟體包編譯平臺針對用戶設置權限的方法
技術領域：
本發明是Iinux平臺下rpm包編譯平臺上使用的一項技術。
背景技術：
Iinux發行版由數量龐大的軟體包組成，為了開發維護這些軟體包就需要一個統一的平臺進行管理，這樣包編譯平臺應運而生。在Iinux發行版裡，有許多的軟體包是用 rpm來進行管理的，本發明也是在rpm軟體包編譯平臺上改進的一項技術。在Iinux眾多的發行版中，每個版本都有自己的編譯平臺，他們利用這個平臺來開發和維護自己的軟體包，目前比較成熟的有koji編譯平臺，opensuse build system等。 不管是那種編譯平臺，他們都能維護多個不同的版本，在開發和維護不同版本的時候給用戶開放一個什麼權限是個很重要的問題，因為在Iinux發行版中，大部分的開發人員都是分布在世界各地的一些自由軟體開發人員，對於這樣的一個群體，我們在開放權限的時候一定要制定詳細的權限策略，以防軟體包被惡意的更改，本發明也是基於這樣一種目的來控制開發人員的權限。目前koji就是一個比較成熟的編譯平臺，koji對於開發人員有權限控制策略，具體來說，koji編譯系統在安裝完成並啟動服務後就處於等待用戶請求的狀態，這個時候所有的配置文件都已經存儲起來，用戶在通過koji客戶端發送請求後koji首先是檢查當前的用戶的身份，身份是由koji客戶端的證書來決定，koji的客戶端需要koji伺服器頒發一個證書，有了這個證書才能連結上koji伺服器。koji伺服器對用戶的身份驗證完成後就會去檢查其權限，本方法也就是在這裡進行的開發。koji編譯系統有自己的權限控制，但它的權限控制有一個問題，一旦一個版本開放給開發人員，那麼所有的開發人員都可以去修改這個版本下的軟體包，這樣對於社區開發是可以的，但對於某個公司發行版本就不太合適，比如一個公司有幾個開發組，每個開發組開發一個版本，版本都放到koji上維護，如果不做進一步的權限控制，那麼一個版本的開發人員就可以去修改其他的版本的軟體包，對於版本開發的對立性就會造成威脅。本發明正是為了解決這個問題，可以提高編譯平臺的安全性和版本間的獨立性。
發明內容
鑑於目前編譯平臺的權限控制的缺陷，本發明的目的就是設計一種權限控制的方法來控制軟體包編譯平臺的用戶權限。為了實現上述目的，軟體包編譯平臺針對用戶設置權限的方法包括下面步驟
(1)在權限配置文件中增加一條權限配置；
(2)在權限驗證代碼中增加一個權限檢查模塊；
(3)在用戶請求執行任務時，該平臺調用這個權限檢查模塊依據修改後的權限配置文件來判斷請求者是否擁有其請求的權限。其中步驟(1)是指在軟體的權限配置文件中重新定義一條所述權限配置，該權限配置包括用戶ID以及版本信息，步驟(2)的權限檢查模塊定義了該權限配置的格式的關鍵欄位，該平臺調用該權限檢查模塊時會讀取這條權限配置，然後獲取關鍵欄位後面的內容， 再與請求者以及請求者所求操作的版本對比。其中步驟(2)的具體方法是修改權限驗證代碼，在裡面加入一個子模塊作為權限檢查模塊，該子模塊負責對新增加的該權限配置進行解析並返回是否通過。其中步驟(3)具體實現方式如下該權限檢查模塊首先從配置文件中讀取權限配置，然後根據用戶的請求進行分析判斷，如果用戶的請求符合權限配置並且允許執行則通過檢查並開始執行任務，否則返回無權限的錯誤。當軟體包編譯平臺管理多個不同的系統版本時，通過不同的權限配置去設置用戶對某個具體的版本的操作權限，提高版本間的安全性和獨立性。在操作中的做法，需要做以下的具體工作
1)、獲取koji軟體包的源碼，修改koji源碼包中的kojihub. py源碼文件，增加一個權限檢查模塊。2)、使用diff工具生成patch文件，將patch文件加入到源碼包。(注在軟體開發過程中，在修改源碼後一般都是通過patch的形式來提交我們的修改，也就是說開發人員在修改完源碼之後將修改前後的兩個文件執行diff -Nuar kojihub. py kojihub. py. old 生成patch文件。)
3)、編譯源碼包，編譯完成之後將會生成rpm包。4)、安裝修改後的koji軟體包。5)、修改koji-hub配置文件，配置用戶權限。6)、啟動koji相關服務。開發人員在向koji請求執行任務的時候就會根據此配置來判斷用戶是否具有相應的權限。
圖1為本發明增加用戶權限控制後的流程圖。圖2為現有技術koji原本的流程圖。
具體實施例方式為使本發明的特徵及優點能得到更清楚的了解，以下結合附圖做更加詳細的說明如圖1所述，在koji系統部署完成後就可以對外提供服務了，這時候開發人員就可以向 koji的管理員申請開發權限，koji管理員負責對開發人員頒發證書、設置權限等。權限設置即是在koji的配置文件中加入新的權限設置策略，然後開發人員就可以向koji伺服器提交任務請求，提交成功後，koji首先會去檢查提交請求的用戶是什麼類型，要麼是管理員權限要麼是普通用戶權限，如果是普通用戶權限接著就會去檢查是否有執行請求的權限， 這個是koji本身就有的權限，也是在koji配置文件中設置，一般的請求有編譯請求，tag請求(既將某個包加入或者移出某個版本)等，這個判斷完成後就會依據結果決定是否執行相應的請求。本發明是在這個koiji配置文件中加入一條新的配置，下面舉例說明其格式tag =
has—perm admin :: allow user wubin tag dist—f13—test :: allow all:: deny build—from—srpm =
has—perm admin :: allow
user wubin tag dist—f13—test :: deny
all:: deny
這是權限配置寫在koji配置文件中的具體書寫格式，可以看出其中包括了用戶名和版本信息，而權限檢查模塊定義了該權限配置的格式的關鍵欄位，藉以讀取上述權限配置，然後獲取關鍵欄位後面的內容，tag表示將包加入或移除某個版本的權限，build_ from_srpm表示設置編譯權限，本方法增加的規則為user wubin tag dist-f 13-test :: allow, user後面跟著是koji編譯平臺用戶，tag後跟著是版本，後的是設置允許還是禁止。有了這樣一條權限配置之後我們就可以對用戶設置對某個版本的操作權限了。koji 運行時對於權限的檢查步驟如下
1)、koji伺服器啟動時開始讀取koji配置文件中的權限配置選項並將之存儲
到內存中。2),koji在收到koji客戶端發出請求後，由權限檢查模塊開始執行一系列的執行請求前的檢查。3)、根據檢查的結果來決定是否執行改請求。其中步驟2做進一步的說明，koji的權限檢查模塊會通過xmlrpc接受到從koji 客戶端傳遞過來的命令行參數，權限檢查模塊對參數進行分析後決定執行什麼樣的響應函數，比如，如果用戶是編譯請求，koji就會執行build函數，build函數在執行前會調用一個 check-policy的函數，這個函數首先對koji配置文件中的權限配置進行截取分析，例如， 截取到第一個欄位是user，這個時候就會去調用一個^erTest的函數，這個函數也就是本方法新增加的代碼(其屬於權限檢查模塊的中的一部分)，UserTest函數會將當前的用戶、 要操作的版本與配置文件中寫的用戶、版本進行比較，結果一致再看是否允許也就是( 後的欄位)，如果檢查都通過就開始執行請求。圖2也就是沒使用本方法的koji的流程圖，與圖1相比就是少了一個對某一具體用戶權限的檢查，其他的與圖1 一樣，這裡不再做出描述。
權利要求
1.一種編譯平臺上用戶權限的設置方法，步驟包括在權限配置文件中增加一條權限配置；在權限驗證代碼中增加一個權限檢查模塊；在用戶請求執行任務時，該平臺調用這個權限檢查模塊依據修改後的權限配置文件來判斷請求者是否擁有其請求的權限。
2.如權利要求1所述的方法，其特徵在於其中步驟(1)是指在軟體的權限配置文件中重新定義一條所述權限配置，該權限配置至少包括用戶信息以及版本信息，步驟(2)的權限檢查模塊定義了該權限配置的格式的關鍵欄位，該平臺調用該權限檢查模塊時會讀取這條權限配置，然後獲取關鍵欄位後面的內容，再與請求者以及請求者所求操作的版本對比。
3.如權利要求1所述的方法，其特徵在於其中步驟(2)的具體方法是修改權限驗證代碼，在裡面加入一個子模塊作為權限檢查模塊，該子模塊負責對新增加的該權限配置進行解析並返回是否通過。
4.如權利要求1所述的方法，其特徵在於其中步驟(3)具體實現方式如下該權限檢查模塊首先從配置文件中讀取權限配置，然後根據用戶的請求進行分析判斷，如果用戶的請求符合權限配置並且允許執行則通過檢查並開始執行任務，否則返回無權限的錯誤。
5.如權利要求1所述的方法，其特徵在於當軟體包編譯平臺管理多個不同的系統版本時，通過不同的權限配置去設置用戶對某個具體的版本的操作權限，提高版本間的安全性和獨立性。
全文摘要
本發明涉及一種軟體包編譯平臺設置用戶權限的方法，本發明是在軟體包編譯平臺軟體koji-1.6.0版本的基礎上進行的二次開發，涉及到一種用戶權限設置的方法，koji對用戶權限的設置是通過一個配置文件來配置，本發明是在這個配置文件中增加一條權限配置，然後在權限檢查代碼中增加一個權限檢查模塊來檢查這個權限配置，用這樣的方式來實現對用戶權限的設置。
文檔編號G06F21/22GK102456113SQ20111034040
公開日2012年5月16日 申請日期2011年10月31日 優先權日2011年10月31日
發明者王昊, 許國昌 申請人:中標軟體有限公司