ICH408I INSUFFICIENT AUTHORITY TO STAT
意外と単純、z/OSのUSS環境でよくある問題です。
しかし、なぜか調査方法が人によって違うと感じてます。
だいたいの人が間違った方向へ進み無駄に時間を浪費する。
なので自分なりの方法およびその解決までの思考を纏めておこうと思う。
一番よく見るメッセージ。(よい例がなかったので手で一部加工したものですが)
ICH408I USER(MYUSER ) GROUP(MYGROUP ) NAME(ME)
/u/myuser/path/file.ext CL(DIRSRCH ) FID(01C7C3E6E5D4E400011E000000000)
INSUFFICIENT AUTHORITY TO STAT
ACCESS INTENT(--X) ACCESS ALLOWED(OTHER ---)
EFFECTIVE UID (0000000023) EFFECTIVE GID (0000000012)
この状況で、file.extへのGROUP PERMISSIONで実行権限は持ってるってのが多いです。
そして、file.extは普通のファイルで、ログとかの出力ファイルであることが多い。
誰も「なぜそのファイルに実行権限がいるんだ？」とか疑問に思わなかったり、
もしくは思っても口に出さないのです。
INSUFFICIENT AUTHORITY TO STATと出る問題が多いで、これを題材にしてます。
当然ながら、ほとんど全ての人が、ファイルやそのすぐ上のディレクトリのパーミッションをまず調べます。
そして、グループパーミッションがあると言うことを誇らしげに見せるのです。
誰も「なんでOTHERとして扱われてるのか？」ということを突き詰めないのです。
そこには大きな落とし穴があって、みんな彷徨いだすんだ。。。
さて、普通はメッセージの意味を咀嚼するもの。ここのページは必読。
RACF processing messages
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.icha600/racfproc.htm
ちょっとAUTHORITY TO の部分が違う例ですが、
全てのディレクトリのパーミッションを調べることが必要です(STATに関しては)。理由はあとで示す。
以下のURLが良い調べ方および解説です。
Obtaining information about z/OS UNIX file and directory violations
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ichb200/ichzb2b016.htm
さて、いくつか補足してみます。
CL(DIRSRCH)って何？
これは監査用のRACFクラスです。
Classes that control auditing for z/OS UNIX System Services
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.icha800/audcls.htm
STATって何？
コマンドですかね。
それはさきほどのURLに記載されてるコマンドでも分かるでしょうし、次のURLの表から見当がつきます。
Audit function codes for z/OS UNIX System Services
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.icha800/afcmvs.htm
STATは、get file statusです。
ちなみにLSTATはget file status - don't resolve ending symlinkというのも念頭に入れておきます。
(まあ、Audit function codes for z/OS UNIX System Servicesは見なくても分かるってオチなんだが。)
さきほどのDIRSRCHの解説として示したURLにて、
DIRSRCHが使われるz/OS UNIX servicesの一覧があるので、そこにもstatはあります
その次にやることは、statについて知ることです。
stat
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.bpxb600/sta.htm
普通の人はここに辿り着くと思います。
しかし、それではいかんのです。
こっちにも辿り着いてください。
stat (BPX1STA, BPX4STA) — Get status information about a file by pathname
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.bpxb100/sta.htm
この部分が大事。
Characteristics and restrictions
To obtain information about a file, you need not have permissions for the file itself;
however, you must have search permission for all the directory components of Pathname.
見てのとおり、全てのディレクトリのパーミッションがいるでしょ？
ここでようやく、冒頭のメッセージが、Xを要求していたのが、ずいぶん上のディレクトリだと分かります。
調べていくと、グループが違ったり、OTHERへの実行権限がないことが判明するのです。
この例で良くあるのは、マウントポイントでの実行権限不足か、それより上のディレクトリの権限不足です。
ごく稀にそれらのディレクトリのOWNERやGROUPを変えるような記事を見ることがありますが、やりすぎです。
さらに追加で書いておくと、通常パーミッションをチェックするとき、どういうフローを経るか？
自分の知識の範囲内だとだいたいこういう順序。
uid=0を調べて、uid=0なら即座にOK。
uidがownerと同じかを調べ、aclをチェックする。
gidがgroupと同じかを調べ、aclをチェックする。
otherのaclをチェックする。(ここまでは普通の話)
owner/group/otherのチェックでNGであっても、UNIXPRIVを持っているかを調べて持ってたらアクセス可能。
本当はもっと多くの分岐が存在するはずで、例えばRESTRICTED USERかを調べるような場合もある。
フローはきっと必要とする権限によっても多少変わるでしょう。
Using UNIXPRIV class profiles
http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.bpxb200/usspriv.htm
MOUNTをREAD ONLYでしてないか？という観点も良いものですが、
それは上記のことをやり終えた後に見る観点だと思います。
OMVS特有のRACFクラスについても後回しだと思う。
