sudoまたはaclまたはsetuid / setgid？
私が本当に理解していない理由で、誰もがすべてのために須藤を望んでいます。職場では、ログファイルを読み取る方法と同じ数のエントリ（head/tail/cat/more、...）もあります。
須藤はここで負けていると思います。
Setgid/setuidディレクトリを組み合わせて使用し、ACLをあちこちに追加したいのですが、起動する前に、ベストプラクティスを知る必要があります。
私たちのサーバーには、％admin、％production、％dba、％usersがあります。つまり、多くのグループと多くのユーザーがいます。各サービス（mysql、Apache、...）には特権をインストールする独自の方法がありますが、％productionグループのメンバーは、構成ファイルまたはログファイルを参照できる必要があります。それらを適切なグループ（mysql ...）に追加し、適切な権限を設定するための解決策はまだあります。しかし、すべてのユーザーをusermodしたくはありません。アップグレードのたびに変更される可能性があるため、標準のアクセス許可を変更したくありません。
一方、ディレクトリでaclsを設定したり、setuid/setgidを混合したりすることは、標準のディストリビューションを「改ざん」することなく簡単に実行できることです。
これについてどう思う ？
Mysqlの例をとると、次のようになります。
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
これは良い習慣だと思いますか、それともusermod -G mysqlを定義して、標準のアクセス許可システムで遊ぶ必要がありますか？
ありがとうございました
ベストプラクティス：sudoersファイルを維持し、Sudoを使用します。
私のパーソナルマシンでは、setuid/gidが好きですが、コンピューター上にいるのは私だけです。 rmのような露骨に危険なものには何もしません。
ベストプラクティス（および最も一般的な）は、Sudoを使用する傾向があります。 Sudoはきめ細かい制御を提供し、構成は複数のマシンを一度に処理できます。
ACLを使用すると、これを補完できます-Sudoは操作をrootとして処理します。 ACLは、ユーザーとグループにディレクトリとファイルへの権限を付与および奪います。私はsetgidとsetuidが合理的なことをすることを期待していません。
ホイールグループも実装します。これにより、セキュリティが向上します。 suプログラムがホイールグループをサポートしているかどうかを確認してください。
もう1つ、ログファイルを読み取る方法としてviewまたはlessがある場合、リスクがあります。これらのプログラムは両方ともシェルアクセスを提供します。
Sudoersオプションはsetuid/setguid/ACLよりも少しコンパクトなようです。
ユーザーをグループ化しないと、ACLSは非常に長くなります。また、ユーザーをグループ化すると、開始したのと同じ場所に戻ります。
より大きな問題は、それを一元管理しないと、アクセス制御がファイルシステム全体に広がることです。もちろん、マクロ、テンプレート、構成管理などで簡単に回避できます。しかし、それは複雑さを軽減するために何もしないまったく別のレイヤーです。
私の小さなDrupalショップでは、すべての作業ファイルにACLをかなり広範囲に使用していますが、すべての管理アクセスにはSudoを使用しています。使用している構成管理レイヤーはAnsibleであり、それについての素晴らしい点は、ユーザー、ユーザーの役割、したがってユーザーが取得するグループ、マシンなどを簡単にテンプレート化します。Sudoersも同様に管理されます。これは最も透過的であるため、私にはかなりのベストプラクティスのようです。
もちろん、私はおそらくあなたほど多くのユーザーやグループを持っていません。 ACLを構成管理に配置することも想像できます。しかし、私の一生の間、多くのマシン、多くのユーザー、および多くのグループをそのように管理する簡単な方法はわかりません。