web-dev-qa-db-ja.com

プロセスGIDとは何で、どのような目的に役立ちますか？

Mod_wsgiのドキュメントを読むと、ワーカープロセスを実行するグ​​ループを選択できることがわかりました。

ファイルのグループ所有権と、そのグループに属するユーザーのみがそのファイルのグループアクセス許可を取得する方法は理解できますが、これが実行中のプロセスにどのように適用されるかはわかりません。

では、プロセスGIDとは何であり、それはどのような目的に役立ちますか？

permissionsprocess
6
Alicia

それは本当にUnixのプロセスを構成するものに帰着します。プロセスは、2つの方法のいずれかで発生します。 fork()関数を介して、またはCのexec()関数の1つを介して。

fork()

fork()は基本的に現在のプロセスのコピーを作成しますが、それに新しいプロセスID（PID）を割り当てます。それは元のプロセスの子です。この関係は、psの出力で確認できます。

_$ ps axjf
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    1  5255  1964  1964 ?           -1 Sl     500   0:39 gnome-terminal
 5255  5259  1964  1964 ?           -1 S      500   0:00  \_ gnome-pty-helper
 5255 18422 18422 18422 pts/1    18422 Ss+    500   0:01  \_ bash
 5255 30473 30473 30473 pts/4    30473 Ss+    500   0:00  \_ bash
30473   782   782 30473 pts/4    30473 Sl     500   1:14  |   \_ evince s.pdf
_

ここで、_gnome-terminal_が親プロセス（PID = 5255）であり、bashがその子プロセス（PID = 18422、PPID = 5255）であることがわかります。

注：PPID =親プロセスID。

プロセスが親からフォークすると、開いているファイルに対して親が現在持っているすべてのファイル記述子のコピーや、親のユーザーIDとグループIDなど、特定のものを「継承」します。

注：最後の2つは、ファイルシステムにアクセスするときにこのプロセスが持つファイルとグループのアクセス許可を識別するものです。

では、プロセスがその親からユーザーとグループIDを継承するだけの場合、なぜすべてがrootまたは単一のユーザーによって所有されているのではないのでしょうか。これがexec()の出番です。

exec()パート＃1

exec()関数ファミリー、具体的にはexecve()は、現在のプロセスイメージを新しいプロセスイメージに「置き換え」ます。 「プロセスイメージ」という用語は、実際には単なるファイル、つまりディスク上の実行可能ファイルです。これが、bashスクリプトが_/usr/bin/time_などのプログラムを実行する方法です。

では、ユーザーIDとグループIDはどうでしょうか。それを理解するために、最初に「ペルソナ」の概念について説明しましょう。

ペルソナ

各プロセスには、有効なユーザーID、有効なグループID、および補足グループIDのセットがあります。これらのIDは、プロセスの特権を決定します。これらは、アクセス制御の目的で「それが誰であるか」を決定するため、まとめて プロセスのペルソナ と呼ばれます。

exec()パート＃2

したがって、「プロセスイメージ」を交換できることに加えて、exec()は、ユーザーおよびグループIDを元の「実際の」IDから「有効な」IDに変更することもできます。

例

このデモンストレーションでは、デフォルトのUID/GIDとしてシェルで開始し、補足のGIDの1つを使用して子シェルを生成し、それを子シェルの有効なGIDにすると、何が起こるかを説明します。

これを実行するには、unixコマンドnewgrpを使用します。 newgrpを使用すると、新しいシェルを生成して、効果的なGIDにしたい補足グループを渡すことができます。

手始めに：

_$ id -a
uid=500(saml) gid=501(saml) groups=501(saml),502(vboxusers),503(jupiter)
_

このシェルは現在、デフォルトのUID/GIDであるsaml＆samlで構成されていることがわかります。いくつかのファイルに触れると、これも当てはまることがわかります。

_$ touch afile1
$ touch afile2
$ ls -l
total 0
-rw-rw-r-- 1 saml saml 0 May 21 23:47 afile1
-rw-rw-r-- 1 saml saml 0 May 21 23:47 afile2
_

ここで、補足グループjupiterを効果的なGIDにします。

_$ newgrp jupiter
$ id -a
uid=500(saml) gid=503(jupiter) groups=501(saml),502(vboxusers),503(jupiter)
_

ここで、いくつかのファイルに触れた場合：

_$ touch afile3
$ touch afile4
$ ls -l
total 0
-rw-rw-r-- 1 saml saml    0 May 21 23:47 afile1
-rw-rw-r-- 1 saml saml    0 May 21 23:47 afile2
-rw-r--r-- 1 saml jupiter 0 May 21 23:49 afile3
-rw-r--r-- 1 saml jupiter 0 May 21 23:49 afile4
_

シェルの有効なGIDはjupiterであることがわかります。したがって、ディスクとの相互作用により、ファイルは通常のデフォルトグループであるjupiterではなくsamlで作成されます。

参考文献

7
slm

プロセスの権限は、プロセスの属性に基づいています。 /etc/passwdおよび/etc/groupのエントリに直接基づいているわけではありません。これらのファイルは、ユーザーがログインしたときにのみ読み取られます。これらは、セッションの初期プロセスが実行されるuidとgidを決定します。同じセッション内の後続のプロセス（子またはより一般的にはその最初のプロセスの子孫）は、それらのuidおよびgidを継承します（ setuid/setgid プログラムを除く）。

ほとんどの場合、プロセスのギッドによって、そのプロセスがアクセスできるファイルが決まります。プロセスのuidがファイルの所有者である場合、所有者権限が適用されます。それ以外の場合、プロセスのギッド（有効または補足）の1つがファイルのグループ所有者である場合、グループのアクセス許可が適用されます。それ以外の場合は、「その他」の権限が適用されます。

1
Gilles 'SO- stop being evil'

ユーザーはファイルにアクセスしません（マウスを入力して移動し、クリックするだけです）。プロセスのみがファイルにアクセスできます。ユーザーがプロセスを開始すると、このプロセスには、そのユーザー（プライマリグループとその補足グループを含む）に関連付けられた権限があります。

1
Hauke Laging