グループメンバーシップとsetuid / setgidプロセス

プロセスデエスカレート経由権限setuid()とsetgid()UID / GID彼らはセットのグループメンバーシップを継承していないようです。

特権ポートを開くためにrootとして実行する必要があるサーバープロセスがあります。その後、特定の非特権uid / gid ^1にエスカレートします-たとえば、ユーザーfoo（UID 73）のuid / gid 。ユーザーfooはグループのメンバーですbar：

> cat /etc/group | grep bar
bar:x:54:foo

したがって、としてログインするとfoo、/test.txt次の特性を持つファイルを読み取ることができます。

> ls -l /test.txt
-rw-r----- 1 root bar 10 Mar  8 16:22 /test.txt

ただし、std=gnu99ルートを実行すると、次のCプログラム（コンパイル）が表示されます。

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main (void) {
    setgid(73);
    setuid(73);
    int fd = open("/test.txt", O_RDONLY);
    fprintf(stderr,"%d\n", fd);
    return 0;
}   

常にアクセス許可が拒否されたことを報告します。これは非ログインプロセスに関係していると思いますが、許可が機能すると想定されている方法をハムストリングのように扱います。

^{1.これはサーバーのSOPであることが多く、Apacheを使用して誰かが報告したため、これを回避する方法があるはずだと思います。Apacheはオーディオグルー​​プに追加されており、サウンドシステムを使用できるようです。もちろん、これはおそらく元のプロセスではなくフォークで起こりますが、実際には私のコンテキストでは同じです（それはsetuid呼び出しの後にフォークされた子プロセスです）。}

問題は、ということですsetuidし、setgid あなたのプロセスにそれが必要とするすべての認証情報を与えるのに十分ではありません。プロセスの承認は、

• そのUID
• そのGID
• その補足グループ
• その機能。

詳細については、man 7 credentialsを参照してください。したがって、あなたの場合、問題はUIDとGIDを正しく設定しているが、プロセスの補足グループを設定していないことです。また、グループにbarはGID 54があり、73はないため、プロセスが属するグループとして認識されません。

やったほうがいい

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <grp.h>

int main (void) {
    gid_t supplementary_groups[] = {54};

    setgroups(1, supplementary_groups);
    setgid(73);
    setuid(73);
    int fd = open("/test.txt", O_RDONLY);
    fprintf(stderr,"%d\n", fd);
    return 0;
}  

OK、ネットを少し巡りました。最初はAPUEがすべての答えを保持すると思っていましたが、間違っていました。そして、私のコピー（旧版）が動作しているので... UnixとLinuxの管理ハンドブックの第5章は有望に見えますが、それはわかりません（最初の2つのエディションのコピーだけでも動作しています）。

私が見つけた小さなリソース（「デーモンライティングUNIX」のグーグル）はすべて、ttyから分離する方法などの重要なステップについて話します。しかし、UID / GIDについては何もしません。不思議なことに、http： //tldp.orgにある広範なHOWTOコレクションでさえ詳細を持っているようには見えません。唯一の例外は、Jason ShortのLinuxデーモンを作ろう-パートIです。SUID / SGIDとそのすべての混乱がどのように機能するかについての詳細は、Chen、Wagner、DeanのSUIDがわかりやすくなっています（USENIX 2002の論文）。ただし、LinuxにはFSUIDという追加のUIDがあります（詳しくは、WolterのUnix非互換性ノート：UID設定関数を参照してください）。

プロセスをデーモン化することは、心の弱い人には絶対にありません。一般的なセキュリティの考慮事項は、D。WheelerのLinuxおよびUnix向けの安全なプログラミングHOWTO-安全なソフトウェアの作成に記載されています。Systemdは、そのほとんどを単純化することを約束します（したがって、セキュリティ上の問題につながるミスの余地を減らします）。デーモンのマニュアルを参照してください。