單使用者共享與多使用者
在我的實驗室中，一組人在一個工作站上工作，他們通過 NFS 共享多個驅動器。他們執行駐留在其中一個 NFS 驅動器中的共享軟體，並在數據所在的 NFS 驅動器上執行它。
目前設置使它們都使用相同的使用者帳戶，讓我們
one在所有主機上呼叫它。實驗室成員登錄joe@myhost以擁有一個具有自己定制的桌面，但對於屬於one, group的科學數據的任何實際工作users，他們必須成為one.請注意，通過將
one帳戶定義為特定於主機的帳戶來實現某些每個使用者的環境定制，因此它們的主目錄是本地的，即one@myhost:/home/one（由於歷史原因，它們都是 UID 502 和 GID 100）。因此，每個使用者的帳戶都可以在指向共享程序one的共同點旁邊設置特定的環境變數。PATH目前在實驗室中正在進行一場辯論，我建議在 Unix 中為不同的使用者擁有不同的帳戶並通過使用組來複製單個使用者的目前功能是更好的做法。
我列出了單一帳戶的以下缺點
- 難以管理多個軟體版本，
- 幾乎毫無意義的審計/記錄，
- 每個人都可以刪除其他人的文件和程序，
- 當一名成員離開實驗室時，最好更改密碼
現在，這個網路在防火牆後面，它只是對入侵者毫無意義且沒有經濟價值的科學數據。此外，在快節奏的科學實驗室中，一切都僅次於生產力，包括安全性。由於數據經常備份，因此刪除數據或程序的能力也不是主要問題。
因為
one帳戶方法非常方便並且是多年前（2001 年？）建立的，我很難說服任何人為每個使用者使用一個帳戶。也許我使用了錯誤的論點，或者也許我剛才描述的場景是這樣一種one方法是一種實用的中間立場，而我的推理不夠靈活。在任何一種情況下，如果您能幫助我找出我是否錯了，或者如果我是對的，我將不勝感激，請建議我如何以其他方式為我的案子辯護。
好吧，我可以想到兩個對立賬戶的觀點。
第一，經典的 unix 組與常見的共享文件樹有一個很大的缺陷，那就是每個使用者和他們執行的每個腳本都需要有一個 umask 來保持文件和目錄組可寫，並且你需要將 group-sticky 位應用於所有目錄。在實踐中，這很難，因為很多腳本都指定了限制性 umask，並且因為如果您
rsync -a或cp -a或tar -x從您擁有的目錄到公共樹中的文件很容易忘記添加組粘性位並將組更改為共享組。你最終得到的是 Joe 擁有的文件子樹，Joe 正在度假或外出吃午飯，有人需要修改這些文件，你必須去找系統管理員來修復它。恕我直言，Unix 權限設計簡單高效，但在現實世界中並不十分實用。第二，如果這個公共文件樹包含二進製文件，並且每個人都將這些路徑添加到他們的 $PATH 中，那麼您根本沒有安全性。你的任何一個使用者都可以劫持整個組，所以他們最好都真正相互信任。此外，您正在使用 NFS，因此如果使用者可以在他們的工作站上接管 root，他們可以以他們喜歡的任何使用者身份訪問中央文件。
至於撤銷使用者帳戶的想法，您可以通過從本地工作站中刪除它們來實現，這是
one儲存密碼的地方（對嗎？）因為使用 NFS，文件伺服器不知道他們輸入了什麼密碼，只有那個他們工作站的核心說“嗨，我是 UID 502，代表我做這些事情”。所以，在你的組織中推動這個問題之前，你應該考慮一下你是否真的可以完成你想要的。
如果您希望程序版本不那麼混亂，也許讓使用者要求您安裝它們，由管理員擁有。當管理員控制 $PATH 中的所有內容時，安全性會更好。
如果您想要單獨的帳戶以便您可以看到誰在更改文件，您可能必須編寫一個守護程序來使用 INotify 監視共享樹（我建議用 Perl 編寫它）並
g+rwx在每個“打開”之後強制位事件，並在每個“寫入”事件之後設置 UID。希望有幫助…