授權管理

Lnode 的主要管理責任有賴於中央管理員來肩負。當 Solaris Resource Manager 設立數種用來指派與管理的資源控制時，也可以選擇性地將特定的管理權限指派給非 root 的使用者，以分散管理使用者的負擔。管理權限可以藉由設定使用者 uselimadm 或 admin 旗標的方式來指派給適當的使用者。uselimadm 旗標為 set 的使用者在 limadm(1MSRM) 程式中和超級使用者享有相同的管理權限。一個 admin 旗標為 set 的群組 header 使用者稱為一位子管理員，並且擁有（如下所述）管理其排程群組內其他使用者的權限。

中央管理員可以建立與限制以 root 為雙親的排程群組來控制整體系統資源的分割。子管理員一般會執行同類的資源控制，但是僅限於其排程群組之內的使用者。子管理員所能分割的資源僅限於已經配置給群組（例如配置給群組 header lnode）的資源。請注意，子管理員可以將 admin 旗標指派給其排程群組中的任何使用者，更進一步地分派其自身的管理責任。

子管理員可以進行下列工作﹕

1. 為其排程群組內的使用者建立與刪除 lnode。

2. 修改其排程群組內任何使用者的資源限制。

   請注意，雖然子管理員可以將一個資源的限制設定得比群組的限制還要大，群組成員所佔用的資源也會被認為是群組 header 所佔用的資源，因此當使用者超出群組 header 的限制時，就會強制實施對個別使用者的限制。

3. 修改其排程群組內的任何 lnode 旗標，但是旗標不能有 noadmin 條件。子管理員指派旗標的工作會進一步受到限制，因而使用者便無法取得子管理員所沒有的權限。之所以採用這種限制是為了防止子管理員繞過 Solaris Resource Manager 的安全措施。

4. 調整他們自己的任何具有 selfadmin 條件的屬性。

子管理員的主要工具是 limadm(1MSRM) 和 limreport(1SRM) 指令。limadm 程式負責執行與一或多位現有使用者的限制、旗標以及其他 Solaris Resource Manager 屬性有關的操作。此程式再加上報告生成器，limreport，這兩個工具可以自行管理排程群組，而不干擾其他不相干的排程群組的資源配置或管理。

超級使用者可以不受所有資源限制的約束，無論其旗標的設定值為何，隨時擁有最高的管理權限，可以新增、刪除與變更使用者帳號，並且能使用 limadm 程式來變更任何 lnode 的使用量、限制或旗標值。

安全問題

Solaris Resource Manager 對於 Solaris 系統有非常完善的管理效果，所以必須非常小心地安裝與維護它，以確保系統的安全性。

系統管理員可以利用多種方式來維護 Solaris Resource Manager 系統的安全。最重要的是，不論在任何 Solaris 系統上，都要確保 root 密碼的私密性。所有知道 root 使用者密碼的人都會取得無限制的系統資源存取權，就好比是中央管理員一樣。

Solaris Resource Manager 內的使用者可以藉由設定其 lnode 內的特定系統旗標，以取得數種特別的管理權限。這樣有助於加強一個系統的安全性，因為可以讓授權的使用者進行必要的任務，而又不需要賦予他們超級使用者的權限。

其他某些權限則必須謹慎處理，不可隨意賦予他人，因為這樣一來會使授權的使用者取得太廣泛的權力。擁有特殊權限的使用者密碼應該小心保護，正如必須小心保護 root 使用者的密碼一樣。

在某些情況下，中央管理員如果在操控排程樹的結構時不夠小心，很可能會造成系統安全上的問題。因此中央管理員必須清楚地了解應如何正確修正排程樹，並且知道如何偵測目前結構中的潛在問題。

uselimadm 和 admin 旗標

中央管理員可以透過一位使用者 lnode 中的 uselimadm 和 admin 旗標，指派 Solaris Resource Manager 內的管理權限。 指向 limadm(1MSRM) 指令的 uselimadm 旗標可以讓使用者取得與中央管理員相同的管理權限。設定給一個群組 header 的 admin 旗標，賦予群組 header 管理其所帶領的群組成員的權限，但無法修改任何群組之外的 lnode 內容。

有 admin 旗標為 set 的群組 header 稱為子管理員。 Solaris Resource Manager 有數種安全措施可以防止子管理員濫用管理權限﹕請參閱"一個典型的應用程式伺服器"以及"Lnode 維護程式"中的詳細說明。

一位子管理員在刪除 lnode 時，應該確定從最底層的 lnode 開始刪除子樹。如果您是從正在刪除的子樹頂層開始的話，便會失去控制被刪除的 lnode 子的權限，因為它們在其雙親被移除之後成為孤立。一旦被孤立後，子管理員便無法修改 lnode，因為它們已經不屬於排程群組之內。

建議的子管理員 lnode 結構

子管理員可能面臨的一個問題是，他們受到和其群組成員一樣的群組限制。例如，如果群組 header lnode 有一個處理限制，那麼該限制也會控制整個群組所用的處理數目，包括群組 header 在內。除非進一步加以限制，否則排程群組中任何使用者都可以設法超出自己的處理限制，不讓子管理員建立新的處理。要防止這種情況，群組管理員就必須對每一位群組成員設定個別的限制。然而，這些限制可能要非常嚴格，才能達到預期的效果。同時迫使子管理員去管理個別的限制，也不符合 Solaris Resource Manager 階層式資源控制的目標。另外一個解決這個問題的方法是，讓管理員變更其群組中的 lnode 結構。不直接將使用者放在自己的 lnode 之下，相反地，他們應該在自己底下建立一個"Control"lnode 來作為他們唯一的子 lnode，然後再讓所有使用者成為此控制 lnode 的子。這樣一來，就會產生如下所示的 lnode 結構。

圖 5-1 子管理員 lnode 結構

參看上圖，子管理員帳號的 UID 會對應標示為"Actual"的 lnode 帳號，也就是樹形的雙親。這也就是 admin 旗標為 set 的 lnode。接著會為"Control"lnode 建立一個虛擬帳號，此帳號不會允許任何登入。標示為"A"、"B"和"C"的 lnode 會與子管理員控制之下的使用者互相對應。

在此例中，"Actual"lnode 的處理限制可以為 100，而"Control"lnode 的限制為 90，同時個別使用者的限制則設為 0。這個設定可以確保即使在使用者 A、B 及 C 使用一共 90 個處理（允許的全部）的情形下，子管理員仍然可以另外建立 10 個處理。不過使用者還是可以互相阻止對方建立處理，唯一的辦法是對那些使用者設定個別的限制。但是在這個例子中，各個限制可以設定為 40，仍然可以在防止單一使用者完全佔用他人資源的同時稍留一點空間。也請注意，這個例子中的子管理員可以為新使用者建立額外的 lnode 來作為"Control"lnode 的子，而不需要擔心如何重新平衡各項限制。