access（2）vs stat（2）を実行してファイルが実行可能かどうかを確認する

Question

statとaccessを使ってファイルが実行可能かどうかを確認すると、結果が異なることがあります。誰も私に2つの方法の違いを説明することができますか？

使用してC：のbashを使用して

#define _GNU_SOURCE 
#include <stdio.h> 
#include <unistd.h> 
#include <fcntl.h>   /* Definition of AT_* constants */ 
#include <assert.h> 
int main(){ 
    const int access_ret = access("start.r",X_OK); 
    const int eaccess_ret = eaccess("start.r",X_OK); 
    const int faccessat_ret=faccessat(AT_FDCWD,"start.r",X_OK,AT_EACCESS); 
    printf("%d,\t%d,\t%d",access_ret, eaccess_ret, faccessat_ret); 
} 

：パイソンを使用して

$ stat start.r 
    File: 'start.r' 
    Size: 2769   Blocks: 8   IO Block: 4096 regular file 
Device: 29h/41d Inode: 58066679 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/  ci) Gid: ( 100/ users) 
Access: 2016-03-22 22:29:31.234892605 -0400 
Modify: 2010-08-06 03:40:03.000000000 -0400 
Change: 2016-02-28 20:39:10.244094828 -0500 
Birth: - 
$ [[ -x start.r ]]; echo $? 
0 

：アプリケーションがsetuidまたはsetgid権限で実行している場合

$ python3 -c ' 
> import os 
> print(oct(os.stat("start.r").st_mode)) 
> print(os.access("start.r",os.X_OK,effective_ids=False)) 
> print(os.access("start.r",os.X_OK,effective_ids=True)) 
> ' 
0o100644 
True 
True 

Answer 1

あなたは違いに気づくでしょう。 access(2)マニュアルページには、ことを伝えます：実際に 操作をしようとしたときに行われるように

はチェックが実効IDではなく、呼び出し元プロセスの実UIDとGID、 を使用して行われている（例えば、オープン（2））のファイル。同様に、ルートユーザーの場合、 チェックでは、有効な機能のセット ではなく、許可された機能のセットが使用されます。非ルートユーザーの場合は、チェックで空の機能セット が使用されます。

stat(2)呼び出しは影響を受けず、実際のファイルシステムのアクセス許可のみを与えます。

2つの例は同じです。両方とも「成功」コードを返します。 0の終了ステータスは$?であり、pythonのTrueも成功を反映しています。

しかし、実施例から明らかでないものがある：ファイルのパーミッションはがを実行していない：

Access: (0644/-rw-r--r--) 

はおそらくファイルには、この結果を生成され、それに適用されるいくつかのACLを持っています。もしそうなら、あなたはgetfaclを使ってこれを見ることができます。 OPはこの情報をバックグラウンドとして提供する新しい質問をするべきです。

深い読み：私はパーマ644とローカルファイルで行ったテストで

• Why does access(2) check for real and not effective UID?
• Setting differing ACLs on directories and files