最近、新しい (Solaris 9) 環境にデプロイする際の手順の 1 つは、一連のファイルとディレクトリを新しい場所にコピーしてから、グループ UID ビットを (「chmod -R g+s」を使用して) すべての環境に適用することでした。すべてに -rwxr-s--- のモードを与えるディレクトリ ツリー内のファイル。その結果、個別に開いて再保存しない限り、シェル スクリプトは実行されませんでした。ファイルをコピーする前に、ターゲットの親フォルダーに g+s を設定したことを付け加えておきます。これにより、すべての新しいディレクトリの初期モードが drwxr-s--- に設定されましたが、ファイルのモードは -rwxr-x--- でした。
最終的にどのステップが問題の原因であるかを突き止めたので、そのステップを切り取って続行することができました。
ただし、ディレクトリやファイルに適用されたときに「s」ビットが何を意味するのかを理解したいと思います。これにより、そもそも問題が発生した理由が説明されることを期待しています。
ディレクトリを設定 g+s すると、そのディレクトリに作成されたすべての新しいファイルのグループがディレクトリのグループに設定されます。
ファイルがデフォルトでグループ書き込みを持つように umask が設定されている場合、これは共同作業の目的で実際に非常に便利です。
注: これは Linux での動作ですが、Solaris ではまったく異なる動作をする可能性があります。
実行可能ファイルの場合、これは、ファイルが実行されるときに、ファイルを実行しているユーザーのグループではなく、ファイルを所有するグループとして実行されることを意味します。
これは、ユーザーが 1 つのコマンドを実行するためだけに特定のグループのアクセス許可を引き受けることができるようにする場合に役立ちます。
ただし、ユーザーがアクセス許可を昇格できるようになるため、セキュリティ上のリスクもあります。このビットが設定されたスクリプトは、ユーザーがこれらの追加のアクセス許可を悪用できるようなことは何もしないことを知っておく必要があります。
SGID (chmod g+s) の非常に便利な説明は次のとおりです: http://www.linuxnix.com/sgid-set-sgid-linuxunix/
SGID (実行時にグループ ID を設定) は、ファイル/フォルダーに与えられる特別な種類のファイル アクセス許可です。通常、Linux/Unix では、プログラムの実行時に、ログインしたユーザーからアクセス許可を継承します。SGID は、ファイルを実行するためにそのグループのメンバーになるためのファイル グループのアクセス許可を持つプログラム/ファイルを実行するための一時的なアクセス許可をユーザーに与えることとして定義されます。簡単に言えば、ユーザーはフォルダ/ファイル/プログラム/コマンドを実行するときにファイル グループの権限を取得します。
実行可能ファイルの場合、実行g+s可能ファイルが実行されるグループ ID をオーバーライドします (通常、親から継承されます)。
$ cp `どの id` id テスト $ ./id-テスト uid=1001(ユーザー1) gid=1001(グループ1) グループ=1001(グループ1),2001(プロジェクト1) $ chgrp project1 id-テスト $ chmod g+s id テスト $ ./id-テスト uid=1001(user1) gid=1001(group1) egid=2001(project1) groups=1001(group1),2001(project1)
(egid は「有効なグループ ID」です。通常は gid の「グループ ID」と同じですが、ここでは異なります。)
ディレクトリのg+s場合、新しいファイルとディレクトリが持つグループ ID をオーバーライドします (通常は作成者から継承されます)。
$ mkdir プロジェクト $ chgrp プロジェクト 1 ファイル 1 $ umask 0022 $ タッチ プロジェクト/ファイル 1 $ ls -l プロジェクト/ファイル 1 -rw-r--r-- 1 ユーザー1 グループ1 0 ファイル1 $ chmod g+s プロジェクト $ タッチ プロジェクト/ファイル 2 $ ls -l プロジェクト/ファイル 2 -rw-r--r-- 1 ユーザー1 プロジェクト1 0 ファイル2
umask最良の結果を得るには、いじる必要があるかもしれません。少なくとも共有書き込みに必要なのと同じくらい寛容なもの、共有読み取りに必要なのと0007少なくとも同じくらい寛容なもの。0027
$ umask 0077 $ タッチ プロジェクト/ファイル 3 $ ls -l プロジェクト/ファイル 3 -rw------- 1 ユーザー 1 プロジェクト 1 0 ファイル 3 $ umask 0027 $ タッチ プロジェクト/ファイル 4 $ ls -l プロジェクト/ファイル 4 -rw-r----- 1 ユーザー 1 プロジェクト 1 0 ファイル 4 $ umask 0007 $ touch project1/file5 $ ls -l プロジェクト 1/ファイル 5 -rw-rw---- 1 user1 project1 0 file5
ファイルの場合、ファイルを実行するグループ ユーザーとしてではなく、ファイルを所有するグループとしてファイルが実行されることを意味します。権限のない操作をユーザーに許可したい場合に使用します。たとえば、私が使用している DBMS では、誰もがデータベースをバックアップできるようにするのが一般的です。「dbms」グループのみがデータベース ファイルへの読み取り/書き込みアクセス権を持っていますが、バックアップ プログラムには g+s が設定されており、直接アクセスすることはできません。
ディレクトリの場合、新しく作成されたディレクトリは、ファイルを作成したグループ ユーザーではなく、ディレクトリを所有するグループによって所有されることを意味します。これの良い例は、sourceforge.net プロジェクトの Web スペースです。プロジェクトの Web サイトを管理している 3 人の開発者を想像してみてください。現在、そのうちの 1 人がファイルを作成すると、その人だけがそのファイルに書き込むことができます (既定では)。これを回避するには、同じプロジェクトのすべてのユーザーも同じグループに属し、ディレクトリにはそのグループに対する rws 権限があるため、ファイルを作成する人は誰でも、グループに対して読み取りおよび書き込み可能として作成されます。
特定の問題を少し拡張するために、sgid実行可能ファイルは、通常は持っていないアクセス許可をユーザーに付与することによって問題を引き起こす可能性があることはすでに指摘されています。これは実行可能ファイルの問題ですが、スクリプト（具体的には「ファイルの先頭にある＃！で識別される外部インタープリターによって実行されるファイル」を意味する）の場合、悪用される可能性のある競合状態を引き起こします。スクリプトの権限で任意のコードを実行するために使用されます。
Unix派生物は、この脆弱性を軽減または排除することを目的とした多くのスキームを長年にわたって実装してきました。そのほとんどには、suidまたはsgidスクリプトの実行を完全に禁止する、またはそれを有効にするためにいくつかのフープをジャンプする必要がある何らかの形式が含まれています。 （通常、スクリプトごとに）。そのようなスキームの1つは、sgidフラグをオンにした後にスクリプトを実行できない原因になります。
使用する必要がある場合：svn+sshを使用する場合のSVNファイルの所有権の問題を修正します。誰かがそれはBDBでのみ起こると私に言いました、しかし私はFSFSストレージでもそのような問題を抱えていました。基本的に、ディレクトリ内の子ファイルの所有権を一貫性のある状態に保ち、他のユーザーがディレクトリに何かを書き込んでいる場合は、u + s / g+sを使用する必要があります。
setuid と setgid の詳細については、こちら