web-dev-qa-db-ja.com

ユーザーをスタッフグループに手動で追加することの意味

これは、Ubuntu 16.04で許可問題として発生しました。 /usr/local/lib/R/site-libraryにインストールされている一部のRライブラリを削除できませんでした。私には許可がなかったことがわかりました。ディレクトリはrootによって所有され、グループはstaffでした。

ユーザーをstaffグループに手動で追加することで、アクセス許可の問題を一時的に解決しました。

Sudo usermod -a -G staff myusername    

# *see blockquote before using this!*

これにより、ライブラリをIDEから削除できます。

しかし、スタッフグループの詳細情報を検索しようとしたときに、トピックに関する明確な資料を見つけることができませんでした。グループが主に意図したものでさえありませんでした。特定のディレクトリのユーザーに同様の「強化された」アクセスを与えるために使用されていると推測できました。

手動でユーザーをスタッフグループに追加することの影響はありますか？

余談ですが、グループのシステム全体のアクセス許可を知るためのコマンドはありますか？たとえば、グループスタッフが書き込み許可を持つディレクトリは何ですか？

ありがとう。

編集：adduserの代わりにusermodを使用することは、この操作に対してより賢明なオプションであることをここに追加する必要があります[以下のコメントを参照してください]

Sudo adduser myusername staff

16.04permissionsusersgroups
6
R.S.

@ mur でナッジされているように、できる限り、自分の質問への回答を投稿しています。ファイルfile:///usr/share/doc/base-passwd/users-and-groups.htmlには、グループと権限に関する詳細情報が含まれています。このページのミラーは次の場所にあります。 ユーザーとグループ

したがって：

スタッフ

Root権限を必要とせずに、ユーザーがシステムにローカル変更（/usr/local、/home）を追加できるようにします。監視/セキュリティにより関連するグループadmと比較してください。

/usr/localを変更する機能は、ルートアクセスと実質的に同等であることに注意してください（/usr/localは/usrの前に意図的に検索パス上にあるため）。 NFSを使用する環境では、別の非rootユーザーの権限を取得する方がこのような環境で簡単になることが多いため、注意してください。

もちろんadmは既にgroupsにあるので、dmesgを実行できます。しかし、手動でstaffに追加する必要がありました

スタッフが所有するディレクトリのリストを記録すると、これらすべてが次のいずれかに属していることがわかります。

Sudo find / -maxdepth 8 -type d -group staff -perm -g=w >>stafflog.txt

/var/local
/usr/local/lib
/usr/local/share

スタッフのメンバーシップによって、共有プログラミング言語ライブラリへの書き込みアクセスが許可されているのも不思議ではありません。

次のいずれかの許可を確認します。

ls -al /var/local

drwxrwsr-x  2 root staff 4096 Apr 11  2014 .
drwxr-xr-x 16 root root  4096 Aug  3 15:55 ..

したがって、スタッフのトリックは、ディレクトリのビット（setguid）を設定することによってシステムによって実行されるようです。 、どのユーザーまたはプロセスがそのディレクトリにファイルを作成しても、そのファイルは常にスタッフグループ全体で共有される権限で実行されます。 こちらを参照

しかし、私はまだこのグループに自分を安全に留めることができるかどうか疑問に思っています。これはラップトップであり、最悪の場合、信頼できるLAN経由でsmbまたはsshを介してアクセスされることを考えると、かなり安全なはずです。 「ルートアクセスと実質的に同等」という言葉は私を怖がらせます。これについてのご意見は大歓迎です。

6
R.S.