Linux のディレクトリとファイルのパーミッション組み合わせと振る舞い

パーミッションとその組み合わせ

Linux のディレクトリとファイルのパーミッションが組み合わさった時、どうふるまうのかを確認します。

ディレクトリ・ファイル単体

Linux のディレクトリ・ファイルのパーミッション表記で使用される文字は以下の定義がされています。

	ファイル	ディレクトリ
“R”読み(4)	ファイルの内容を表示	ディレクトリ内のリスト表示
“W”書き(2)	ファイルの上書き、変更	ディレクトリ内にファイル作成、削除
“X”実行(1)	実行ファイルの実行	そのディレクトリに移動

ファイルのパーミッション設定、ディレクトリは要注意 | VPSサーバーでWebサイト公開 備忘録 ~Linux、MySQLからAJAXまで

w権限で「ファイルの作成・削除」はディレクトリに、「ファイルの上書き・変更」はファイルに権限付与されることにご注意ください。

親ディレクトリと子ディレクトリの関係

• 子ディレクトリの操作を行うためにはルートディレクトリ～親ディレクトリまでのx権限が必要となります。
  • 以降に挙げる全ての操作の前提となります。
• 子ディレクトリ内のリスト表示には子ディレクトリのr権限が必要となります。
  • 子ディレクトリのx権限は必須ではありません。
  • ただし、子ディレクトリのx権限もないと、lsコマンド実行時に子ディレクトリ内のファイルのアクセス許可がないというエラーが発生します。
• 子ディレクトリ内にファイル作成・削除するには子ディレクトリのwx権限が必要となります。
• 子ディレクトリに移動するには子ディレクトリのx権限が必要となります。

ディレクトリとファイルの関係

• ファイルの操作を行うためには、ルートディレクトリ～ファイルの存在するディレクトリまでのx権限が必要となります。
  • 以降に挙げる全ての操作の前提となります。
• ファイルの内容を表示するにはファイルのr権限が必要となります。
• ファイルの上書き・変更にはファイルのw権限が必要となります。
  • ファイルをエディタなどで編集・保存する際はr権限も必要となります。
• 実行ファイルの実行にはファイルのrx権限が必要となります。

まとめ

子ディレクトリとその中のファイル操作することを想定したパーミッション設定をまとめます。これらをベースに必要最小限の権限のみを設定しましょう。

◎ルートディレクトリ～親ディレクトリ

rx権限（リスト表示・移動）を設定します。

◎子ディレクトリ

rx権限（リスト表示・移動）を設定します。

ディレクトリ内のファイル作成／削除があればw権限（ファイル作成・削除）も設定します。この時、ルートディレクトリ～親ディレクトリにw権限を設定する必要はありません。

◎ファイル

読み取りのみ：r権限
読み書きする：rw権限
実行する：rx権限（＋必要に応じてw権限）

検証結果

今回の検証では設定するパーミッションにちなんだ名前をディレクトリ・ファイルに付けました。

名前	パーミッション
none	---
x	--x
w	-w-
wx	-wx
r	r--
rx	r-x
rw	rw-
rwx or all	rwx

親ディレクトリと子ディレクトリの関係

親ディレクトリと子（サブ）ディレクトリにそれぞれパーミッションが設定された時、子ディレクトリ内でどのような操作が可能かを確認します。

操作	コマンド
ディレクトリ内のリスト表示	ls /all/{updir}/{dir}
ディレクトリ内にファイル作成・削除	touch /all/{updir}/{dir}/a.txt
そのディレクトリに移動	cd /all/{updir}/{dir}

{updir}：親ディレクトリ
{dir}：子ディレクトリ
a.txtは事前に存在しない。

子ディレクトリのx権限有無でlsコマンドの実行結果がどのように変わるかを示します。
子ディレクトリのx権限がないと、リスト表示はできますがアクセス許可がないというエラーが発生します。

$ ls /all/x/r
ls: /all/x/r/none にアクセスできません: 許可がありません
ls: /all/x/r/r にアクセスできません: 許可がありません
ls: /all/x/r/rw にアクセスできません: 許可がありません
ls: /all/x/r/rwx にアクセスできません: 許可がありません
ls: /all/x/r/rx にアクセスできません: 許可がありません
ls: /all/x/r/w にアクセスできません: 許可がありません
ls: /all/x/r/wx にアクセスできません: 許可がありません
ls: /all/x/r/x にアクセスできません: 許可がありません
none  r  rw  rwx  rx  w  wx  x
$ ls /all/x/rx
none  r  rw  rwx  rx  w  wx  x

検証結果を一覧にして示します。"OK"が操作可能です。

updir	dir	表示(ls)	作成、削除(touch)	移動(cd)
none	none
none	x
none	w
none	wx
none	r
none	rx
none	rw
none	rwx
x	none
x	x			OK
x	w
x	wx		OK	OK
x	r	OK
x	rx	OK		OK
x	rw	OK
x	rwx	OK	OK	OK
w	none
w	x
w	w
w	wx
w	r
w	rx
w	rw
w	rwx
wx	none
wx	x			OK
wx	w
wx	wx		OK	OK
wx	r	OK
wx	rx	OK		OK
wx	rw	OK
wx	rwx	OK	OK	OK
r	none
r	x
r	w
r	wx
r	r
r	rx
r	rw
r	rwx
rx	none
rx	x			OK
rx	w
rx	wx		OK	OK
rx	r	OK
rx	rx	OK		OK
rx	rw	OK
rx	rwx	OK	OK	OK
rw	none
rw	x
rw	w
rw	wx
rw	r
rw	rx
rw	rw
rw	rwx
rwx	none
rwx	x			OK
rwx	w
rwx	wx		OK	OK
rwx	r	OK
rwx	rx	OK		OK
rwx	rw	OK
rwx	rwx	OK	OK	OK

ディレクトリとファイルの関係

ディレクトリとファイルにそれぞれパーミッションが設定された時、ファイルに対してどのような操作が可能かを確認します。

操作	コマンド
ファイルの内容を表示	cat /all/{dir}/{file}.sh
ファイルの上書き・変更	touch /all/{dir}/{file}.sh
実行ファイルの実行	/all/{dir}/{file}.sh

{dir}：ディレクトリ

{file}.shは以下の内容で事前に用意しました。

#!/bin/sh
echo "Hello, world!"

子ディレクトリにx権限しかなく、ディレクトリ内のリスト表示ができなくても、ファイルを取り扱うことは可能です。

$ ls /all/x
ls: ディレクトリ /all/x を開くことが出来ません: 許可がありません
$ /all/x/rx.sh
Hello, world!

検証結果を一覧にして示します。"OK"が操作可能です。

dir	file	表示(cat)	変更(touch)	実行(sh)
none	none
none	x
none	w
none	wx
none	r
none	rx
none	rw
none	rwx
x	none
x	x
x	w		OK
x	wx		OK
x	r	OK
x	rx	OK		OK
x	rw	OK	OK
x	rwx	OK	OK	OK
w	none
w	x
w	w
w	wx
w	r
w	rx
w	rw
w	rwx
wx	none
wx	x
wx	w		OK
wx	wx		OK
wx	r	OK
wx	rx	OK		OK
wx	rw	OK	OK
wx	rwx	OK	OK	OK
r	none
r	x
r	w
r	wx
r	r
r	rx
r	rw
r	rwx
rx	none
rx	x
rx	w		OK
rx	wx		OK
rx	r	OK
rx	rx	OK		OK
rx	rw	OK	OK
rx	rwx	OK	OK	OK
rw	none
rw	x
rw	w
rw	wx
rw	r
rw	rx
rw	rw
rw	rwx
rwx	none
rwx	x
rwx	w		OK
rwx	wx		OK
rwx	r	OK
rwx	rx	OK		OK
rwx	rw	OK	OK
rwx	rwx	OK	OK	OK

エルブラン・セマンティクス(Herbrand Semantics)理解メモ

はじめに

データベースのトランザクション（特にスケジュール）の理論を勉強しようとすると、エルブラン・セマンティクス(Herbrand Semantics)の理解が必要となります。

Herbrand Semantics の解説は以下の本・章にあります。

Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery (The Morgan Kaufmann Series in Data Management Systems)

該当章：3.5 Herbrand Semantics of Schedules

ですが、本が英語であることに加え、読み解くには数学の知識も必要となります。そこで、周辺知識を含めて理解していく過程をエントリにまとめることにしました。

解説

ここではトランザクションが失敗（ロールバック）することを考えません。

次のようなスケジュールsを仮定します。

1. a step r_i(x) ∈ s of a transaction t_i ∈ trans(s) reads the value written by the last w_j(x) ∈ s, j ≠ i, that occurs before r_i(x);
2. a step w_i(x) ∈ s writes a new value that potentially depends on the values of all data items that t_i has read from the database or from other transactions in active(s) ∪ commits(s) prior to w_i(x).

ここでは以下のことを仮定しています。

1. r_i(x)は最後にwriteされた値xをreadする。
2. w_i(x)はそのトランザクションt_iがw_i(x)の前にreadした全ての値に依存している。

DEFINITION 3.3 Herbrand Semantics of Steps

Let s be a schedule. The Herbrand semantics H_s of steps r_i(x), w_i(x) ∈ op(s) is recursively defined as follows:

1. H_s(r_i(x)) := H_s(w_j(x)), where w_j(x), j ≠ i, is the last write operation on x in s before r_i(x).
2. H_s(w_i(x)) := f_ix(H_s(r_i(y₁)),...,H_s(r_i(y_m))), where the r_i(y_j), 1 ≤ j ≤ m, represent all read operations of t_i that occur in s before w_i(x), and where f_ix is an uninterpreted m-ary function symbol.

H_s は Herbrand semantics のことです。

1. H_s(r_i(x)) := H_s(w_j(x))

H_s(r_i(x)) を H_s(w_j(x))と定義するということです。
参考：数学記号の表 - Wikipedia
r_i(x) は w_j(x) に等しい、つまり最後にwriteした値をreadする、ということです。

2. H_s(w_i(x)) := f_ix(H_s(r_i(y₁)),...,H_s(r_i(y_m)))

"m-ary function"とは「m項関数」と呼ばれ、m個の引数をもつ関数のことです。

関数f_ixの"i"はトランザクションT_iのこと、"x"は値xのことです。
関数f_ixの引数はトランザクションT_iでw_i(x)以前の全てのread操作のH_sです。

ここでのポイントは read/write が m-ary function に変換可能ということにあります。

例えば、次のスケジュールを考えます。
s = r₁(x)r₂(y)w₂(x)w₁(y)c₂c₁

値x, yには初期値があるはずです。これをトランザクションt₀が書き込んだものと仮定すれば、次のスケジュールになります。
s = w₀(x)w₀(y)c₀r₁(x)r₂(y)w₂(x)w₁(y)c₂c₁

これを踏まえて以下の展開を行います。

s = w₀(x)w₀(y)c₀r₁(x)r₂(y)w₂(x)w₁(y)c₂c₁

is as follows, where f_0x() and f_0y() are 0-ary functions (constants):

H_s(w₀(x)) = f_0x()
H_s(w₀(y)) = f_0y()
H_s(r₁(x)) = H_s(w₀(x)) = f_0x()
H_s(r₂(y)) = H_s(w₀(y)) = f_0y()
H_s(w₂(x)) = f_2x(H_s(r₂(y)) = f_2x(f_0y())
H_s(w₁(y)) = f_1y(H_s(r₁(x)) = f_1y(f_0x())

Herbrand semantics H_s を展開していくと、どのread/writeもf_0x()/f_0y()を含む関数の式に変換されます。つまり、read/writeを初期状態と関数の式で表現できたということであり、異なるスケジュールのトランザクションの各ステップ(read/write)が同じ結果となるかを数式で比較可能となります。Herbrand semantics で表現することの価値はここにあります。

具体例については以下の記事を参照ください。
Serializablitiyとは？ １. Final State Serializabilityについて - Qiita
Serializablitiyとは？ 2. View Serializabilityについて - Qiita
Herbrand Semantics の式の表現は異なりますが、実現していることは同じです。

DEFINITION 3.4 Herbrand Universe

Let D = {x, y, z,...} be a (finite) set of data items (representing the data of the underlying data server(s)). For a transaction t, let op(t) denote the set of all steps of t. The Herbrand universe HU for transactions t_i, i > 0, is the smallest set of symbols satisfying the following conditions:

1. f_0x() ∈ HU for each x ∈ D, where f_0x is a 0-ary function symbol (i.e., a constant);
2. if w_i(x) ∈ op(t_i), |{r_i(y) | (∃y ∈ D) r_i(y) <_ti w_i(x)}| = m, and if v₁,..., v_m ∈ HU, then f_ix(v₁,...,v_m) ∈ HU, where f_ix is an m-ary function symbol.

"{r_i(y) | (∃y ∈ D) r_i(y) <_ti w_i(x)}"は集合の内包的記法です。
{ (代表元) | (代表元の満たすべき条件)} です。例えば {x | x ∈ S, P(x)} は S の元のうち、命題 P(x) が真であるものすべてを集めた集合を意味しています。
参考：数学記号の表 - Wikipedia

また、集合Aの要素数は|A|で表現されます。例えば、A={1,2,3,4}, |A|=4です。
参考：集合の要素数

つまり、"|{r_i(y) | (∃y ∈ D) r_i(y) <_ti w_i(x)}| = m"とはT_iがw_i(x)の前にreadした回数をmとする、ということです。

これを踏まえて DEFINITION 3.4 をまとめると、

1. f_0xは0項関数で定数だ。
2. f_ixはm項関数（m個の引数を持つ）で、mはT_iがw_i(x)の前にreadした回数に等しい。

となります。

2.でf_ixとw_i(x)の関係がピンとこない場合は DEFINITION 3.3を再確認してください。下記の式で w_i(x)の Herbrand Semantics は f_ixの関数で表現されることが示されています。
H_s(w_i(x)) := f_ix(H_s(r_i(y₁)),...,H_s(r_i(y_m)))

DEFINITION 3.5 Schedule Semantics

The semantics of a schedule s is the mapping

H[s] : D → HU

defined by

H[s](x) := H_s(w_i(x))

where w_i(x) is the last operation from s writing x, for each x ∈ D.

"H[s] : D → HU"とは写像の表記です。

写像とは"f : A → B"の形で表現され、Aの要素が決まるとBの要素が決まる対応関係です。
"f(A) = B"のように、fはAを引数にとってBとなる、と考えるとわかりやすいかもしれません。
参考：写像とは

つまり、"H[s](x) := H_s(w_i(x))"は "H[s](x)" がスケジュールsの値xの最終的な状態（最後のwrite操作）を Herbrand Semantics で表現する、ということを表しています。

s = w₀(x)w₀(y)c₀r₁(x)r₂(y)w₂(x)w₁(y)c₂c₁

H[s](x) = H_s(w₂(x)) = f_2x(f_0y())
H[s](y) = H_s(w₁(y)) = f_1y(f_0x())
※引用に際して一部省略

この例でスケジュールsの値xに対する最後のwrite操作はw₂(x)、値yに対する最後のwrite操作はw₁(y)であり、H[s](x), H[s](y) は これらのwrite操作を Herbrand Semantics で表現するということです。

MANABIYA「技術者としての成長のための技術トレンド」聴講メモ

はじめに

MANABIYA(【国内最大級のエンジニア向け技術祭典】MANABIYA -teratail Developer Days-)
2018/03/24（土）1時間目
技術者としての成長のための技術トレンド
スピーカー：及川 卓也 さん [エンジニアリング・プロダクトアドバイザー]
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

#MANABIYA 2018 技術者としての成長のための技術トレンド from Takuya Oikawa

（2018/07/08 追記）
ログミーTechで全文の書き起こし記事が公開されました。
及川卓也氏が振り返る自身のキャリア エンジニアとして生き残るための「偶然と必然」とは何か - ログミーTech（テック）

【参考】としている個所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。

何をやっている人か？

本当は技術・製品・組織を均等に取り組みたかったが、依頼される仕事は組織作りが多い。

経歴紹介を兼ねた自分史と技術トレンド

DEC時代

DECはUNIX/C言語/Ethernetといった重要な技術を開発していた。（及川さんの）入社当時はIBMに追いつけ追い越せの時代だった。

当時は第2次AIブーム真っ盛りで、DECもAI技術センターを作り、「ナレッジエンジニア養成コース」を開講していた。
この技術センターへの配属を希望したが叶わず、営業サポートに配属されることになった。そこで担当した製品はAll-IN-1、略してA1。AIとA1の表記は似ているけどそれじゃない感…。

DECがダウンサイジングのトレンドのきっかけを作った。

初期のWindowsはまともに使えず、バージョン3からようやく使い物になった。
昔、マイクロソフト製品はバージョン3から使い物になるといわれていたが、その言葉通りだった。

当時、パーソナルコンピュータやWindowsはおもちゃ扱いだった。

Windows NT の開発に日本からエンジニアを出してといわれ、参加することになった。

【参考】
この時点で及川さんはまだDEC社員でした。

日本DEC時代の後半は、同社が開発したRISCチップ「Alpha」向けのWindows NTの開発を手掛けていた。

グーグルでChrome開発に関わった及川卓也氏が「Qiita」開発元Incrementsの14人目の社員に | TechCrunch Japan

当時のDECは落ちぶれつつあり、起死回生を狙ってCPU（Alphaプロセッサー）開発に乗り出していた。だが、CPU開発に必要な投資額の大きさが致命傷となってしまった。

Windows Vista のライバルは Windows XP と言われていた。他社製品に敵はおらず、VistaからXPへ乗り換えてくれないことが最大の懸念とまで言われた。

マイクロソフト時代

カウンセラーやヘッドハンターからのアドバイスにより、Windowsしか知らないことに危機感を覚えた。そこで、GPKIやIPv6といった業界標準の技術に携わるようにした。

【参考】

日本マイクロソフト時代に感じたことです。ヘッドハンターに友だちを作るのが好きなんですが（笑）、自分に転職希望がない時でも年1回程度で情報交換をしています。ある時言っていただいた言葉が「Microsoftの技術が長いから、転職先はMicrosoftのパートナー企業が対象になる。可能性を広げるなら経営や営業、マーケティングはいかがですか」というものでした。自分は技術にこだわりたかったものの、Microsoft以外の技術って何だろうかと考えました。

1つの会社に縛られない方がいい--及川卓也氏が語る「看板を彩る生き方」 - (page 3) - CNET Japan

これはツイートしてほしくないのだが、Windows Live は失敗製品だった、と社員としてすら感じていた。

【参考】
ツイートしてほしくないとのことなので本記事にも載せないつもりでしたが、以前に別記事で取り上げられていました。

日本マイクロソフト社内を見渡すと、Windows Liveブランド製品をプッシュしていました。しかし、Windows以外の製品にあまり愛を感じられなかったこともあり、社員視点でも「これはダメだろう（笑）」と。

1つの会社に縛られない方がいい--及川卓也氏が語る「看板を彩る生き方」 - (page 2) - CNET Japan

自分自身がトレンドに乗れなかったとしても、その中にいて感じることができたことはよかった。

余談だが、入国審査では係員と雑談になることがある。そこで過去の経歴を聞かれ、DEC・マイクロソフト・Googleと渡り歩いたことを話すと、次はどこに行くんだ？と聞かれた。株でも買いたかったのかも（笑）。

インターネットを好きな人、自分より詳しい人は大勢いたが、みんなマイクロソフトが嫌いだった。でも自分は知っていることが強みになった。

エンジニアとしての成長とは

学習ループを回す

成長のためには知識のグラデーションの濃いところへシフトする（知っている ⇒ 使える ⇒ 使いこなせる）ことが必要となる。
そのためには学習が必要となる。でも、学習だけでは足りず、経験も必要となる。

学習 ⇒ 知識 ⇒ 経験という学習ループを回す。経験を通じた学習で技能になる。

巷のプログラミングスクールでの学習の問題点は勉強したことをそのあと実践（経験）につなげられないこと。

経験だけでは価値がない。経験は年数じゃない。その経験を活かして何をできるのか（技能）が大事だ。

経験から始めるのでななく、学習から始める。知らないことにはチャレンジできない。

（自然）言語学習を例にとって

通訳を雇うことは経済合理性を考えれば理にかなっている。
でも本当にそうなのか。エンジニアなら英語に触れなくてすむ環境にいることはリスクだ。
勉強しなくて良いと感じたら、目的への追求が足りないのでは、と考えてみる。

言語を知っていればそれを通じて学びやすい。これは言語間の距離、ドメインともいえる。複数の言語を学ぶのであれば、距離についても意識する必要がある。

成長戦略

成長には戦略が必要だ。

T字型人材になれ、とよく言われる。
ここでフルスタックとはTの上棒を太くすることに当たる。
Tの縦棒は軸（専門）に当たる。

（n次元幾何学的空間における容積を最大化する、のスライドを示し）軸となる技術とバツの軸は近すぎて強みにしづらい。点線の軸を選ぶ方がよい。空間における容積を最大化する。

この空間における容積を最大化するということについて、藤原和博さんがわかりやすく説明している。

【参考】
スライド中に示されている藤原さんの講演記事です。
年収1000万円から1億円を目指すための人生戦略 - ログミー

プロになる目安の１万時間は毎日3時間で10年かかる。仕事にすればもっと短くできる。

藤原さんはリクルートで営業とマネジメントを学んだ。次は校長になることで全く違う軸を得た。これにより、（n次元幾何学的空間の）空間を広げることができた。

距離が遠い・ベクトルの異なるドメインを選ぶことが大切。なぜなら、希少化につながるから。また、仕事で同じドメインの技術が要求されたとき、効率よく学べることになる。

トレンドの当たり外れは大事でない。トレンドは繰り返す。その時に活きてくる。

及川さんの転移学習の例。
最近はBlockchainに興味を持っているが、P2PやPKIの経験があったので理解しやすい。
WindowsがベースにあったからChromeもスムーズに理解できた。

技術トレンドとエンジニアとしての成長

何に取り組むべきかは結局のところ気持ちが大事。興味を持ったらやろう。

仕事で必要ないなら必要にすれば良い。必ずしもできるわけではないが、そうあろうとする。仕事でやるために会社に提案するもよし、転職するもよし。

「外発的動機を持てるような環境を作る・移る」ことは英語の勉強でも一緒。（及川さんの場合）英語を使う部署に行き、英語での定例ミーティングを設定することで環境を作った。

メインフレームからみればミニコンやパソコンはおもちゃだった。でも、そうした「おもちゃ」レベルの技術に置き換えられていく。
これを破壊的イノベーションという。

【参考】
「破壊的イノベーション」の原典といえる本です。

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)

一番大事なことは、技術を好きだと思う気持ち。自分が興味を持てるかどうかだ。

おわりに

この講演の後に続く、まさに後編ともいえる 西尾 泰和 さんの講演資料もぜひ参照ください。併せて読むことで未来へ進む勇気をもらえるはずです。
西尾さんの講演の聴講メモを別エントリにまとめました。資料へのリンクもあります。
MANABIYA「エンジニアのための自分経営戦略」聴講メモ - ぱと隊長日誌