難易度は Level 1(やさしめ)〜Level 5(難関) の5段階です。
LinuC レベル3 3SS試験のサンプル問題(本番形式・解説付き)
LinuC レベル3 3SS試験(LPI-Japan・LinuC-3SS(セキュリティスペシャリスト))の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試 第1回(60問)の冒頭から抜粋したオリジナル問題です。当サイトは全420問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。
設問1
開発グループ dev が共同で使うディレクトリ /srv/share/proj について、既存ファイルの権限はすでに調整済みである。今後このディレクトリ配下に新しく作成されるファイルとサブディレクトリに対して、dev グループの読み書きが自動的に許可される状態を維持したい。この要件を満たす設定として適切なものはどれか。
- setfacl -m g:dev:rwx /srv/share/proj を実行し、ディレクトリのアクセス ACL に dev グループのエントリを追加する
- setfacl -R -m g:dev:rwx /srv/share/proj を実行し、配下の既存のファイルとディレクトリへ再帰的に dev グループのエントリを追加する
- setfattr -n user.acl.dev -v rwx /srv/share/proj を実行し、拡張属性として dev グループへ与える権限を記録する
- setfacl -d -m g:dev:rwx /srv/share/proj を実行し、ディレクトリのデフォルト ACL に dev グループのエントリを追加する(正解)
解説
新規に作られるオブジェクトへ権限を引き継ぐ役割を担うのはデフォルト ACL であり、setfacl の -d で設定する。アクセス ACL(ACL Entry)はそのディレクトリ自身への権限を決めるだけで継承には関与しない、という点がデフォルト ACL との分かれ目になる。デフォルト ACL を持つのはディレクトリだけである。
他の選択肢が誤りである理由
- 「setfacl -m g:dev:rwx /srv/share/proj を実行し、ディレクトリのアクセス ACL に dev グループのエントリを追加する」-d を付けない setfacl -m はディレクトリ自身のアクセス ACL を変更する操作である。そのディレクトリを開く権限は変わるが、あとから作られるファイルへは引き継がれない。
- 「setfacl -R -m g:dev:rwx /srv/share/proj を実行し、配下の既存のファイルとディレクトリへ再帰的に dev グループのエントリを追加する」-R は実行した時点で存在するファイルとディレクトリへ再帰的に適用する操作であり、実行後に作成されたオブジェクトは対象外になる。継承を担うのはデフォルト ACL である。
- 「setfattr -n user.acl.dev -v rwx /srv/share/proj を実行し、拡張属性として dev グループへ与える権限を記録する」user 名前空間の拡張属性はアプリケーションが自由に使えるメタデータの置き場であり、カーネルのアクセス判定には参照されない。
設問2
/srv/data にはデフォルト ACL として user:alice:rwx が設定されている。ユーザー alice がこのディレクトリ内で touch により新しいファイルを作成し、getfacl でそのファイルを確認したところ、alice のエントリは rwx のまま残っているのに、実効権限が rw- になっていた。この結果が生じる理由として適切なものはどれか。
- デフォルト ACL は基本エントリだけを新規ファイルへ写す仕組みであり、名前付きユーザーのエントリは所有グループの権限まで切り下げられて継承されるため
- デフォルト ACL の各エントリは、ディレクトリ自身のアクセス ACL とマスクエントリの両方と論理積が取られたうえで新規ファイルへ適用されるため
- 新規ファイルはディレクトリのデフォルト ACL をアクセス ACL として受け継ぎ、作成時に指定された mode に含まれない権限が取り除かれるため(正解)
- touch で作られたファイルにはアクセス ACL が付与されず、アクセスのたびに親ディレクトリのデフォルト ACL が評価されて権限が決まるため
解説
新規オブジェクトは親ディレクトリのデフォルト ACL をアクセス ACL として受け継いだあと、所有者・マスク・other の各エントリが作成時にプロセスの指定した mode と論理積を取られる。通常のファイル作成は実行権を要求しないためマスクから実行権が落ち、名前付きユーザーのエントリ自体は rwx のまま残っても実効権限は rw- に絞られる。デフォルト ACL が無いディレクトリで umask が効くのとは別の経路であり、デフォルト ACL がある場合の絞り込みは umask ではなく mode との交差による。
他の選択肢が誤りである理由
- 「デフォルト ACL は基本エントリだけを新規ファイルへ写す仕組みであり、名前付きユーザーのエントリは所有グループの権限まで切り下げられて継承されるため」デフォルト ACL は名前付きユーザーや名前付きグループのエントリも含めてアクセス ACL へ写される。所有グループの権限まで切り下げるという規則は存在しない。
- 「デフォルト ACL の各エントリは、ディレクトリ自身のアクセス ACL とマスクエントリの両方と論理積が取られたうえで新規ファイルへ適用されるため」新規オブジェクトの ACL を決めるのは、親ディレクトリのデフォルト ACL と作成時の mode の組み合わせである。親ディレクトリのアクセス ACL は新規オブジェクトの ACL 初期化には関与しない。
- 「touch で作られたファイルにはアクセス ACL が付与されず、アクセスのたびに親ディレクトリのデフォルト ACL が評価されて権限が決まるため」作成されたファイルには自身のアクセス ACL が付与される。親ディレクトリのデフォルト ACL がアクセスのたびに参照される仕組みではない。
設問3
共有ディレクトリ /srv/project に対し、以後そこへ新規作成されるファイルとサブディレクトリへ自動的に同じ権限が付くよう、setfacl でデフォルトACLとして設定したい。setfacl に付けるオプション名だけを入力せよ(エントリ本体やパスは含めない)。
入力形式(コマンドを打ち込んで答える問題です)
-d(正解)
別解: --default
解説
デフォルトACLはディレクトリにだけ設定でき、その配下に新規作成されるオブジェクトの初期ACLの雛形として働く。既存ファイルの実効権限を決めるアクセスACLとは別枠で保持されるため、-d を付けずに書いた設定はすでにあるファイルにしか効かない。エントリ側に d: の接頭辞を書く形も同じ意味になる。
設問4
運用チーム向けの共有ディレクトリで、名前付きユーザーのエントリ user:alice:rwx を追加したところ、getfacl の出力に #effective:r-- という注記が付き、alice が書き込めない状態になった。原因を切り分けたうえで、以後この共有で同じ事象を起こさないための設計として適切なものはどれか。
- 所有者のエントリが実効権限の上限を決めているため、所有者の権限を rwx へ設定し、以後は所有者を付け替える運用を避ける
- 実効権限の上限を決めるマスクエントリが原因であるため、setfacl でマスクを明示的に rwx へ設定し、以後はマスクを含めた形で ACL を設定する運用に統一する(正解)
- other のエントリが実効権限の上限を決めているため、other の権限を rwx へ設定し、以後は他ユーザーの権限を絞る運用を避ける
- デフォルト ACL のマスクが実効権限の上限になっているため、デフォルト ACL のマスクを rwx へ設定し、以後はデフォルト ACL 側で権限を決める運用に統一する
解説
マスクエントリは、名前付きユーザー・名前付きグループ・所有グループの各エントリに与えられる権限の上限を決める。エントリ自体に rwx があってもマスクが r-- なら実効は r-- に絞られ、getfacl はそれを #effective の注記で示す。所有者のエントリと other のエントリはマスクの影響を受けない、という対比を押さえておく。なお setfacl はマスクを明示しない限りマスクを再計算するため、意図した値を保つならマスクを式に含めて指定する。
他の選択肢が誤りである理由
- 「所有者のエントリが実効権限の上限を決めているため、所有者の権限を rwx へ設定し、以後は所有者を付け替える運用を避ける」所有者のエントリはマスクの適用対象外であり、その権限を広げても名前付きユーザーの実効権限には効かない。
- 「other のエントリが実効権限の上限を決めているため、other の権限を rwx へ設定し、以後は他ユーザーの権限を絞る運用を避ける」other のエントリもマスクの適用対象外であり、その権限を広げても名前付きユーザーの実効権限は絞られたままになる。
- 「デフォルト ACL のマスクが実効権限の上限になっているため、デフォルト ACL のマスクを rwx へ設定し、以後はデフォルト ACL 側で権限を決める運用に統一する」アクセス ACL の実効権限を決めるのはアクセス ACL 側のマスクである。デフォルト ACL のマスクは、以後作られるオブジェクトの初期値に関わる。
設問5
名前付きユーザー bob へ書き込みを許可する拡張 ACL が設定されたファイルに対し、別作業のなかで chmod g-w が実行された。その後、bob からファイルへ書き込めなくなったが、getfacl の出力では bob のエントリ自体は rw- のままだった。この事象の説明として適切なものはどれか。
- マスクを持つファイルではグループの権限ビットがマスクに対応し、chmod がマスクを r-- に書き換えたため(正解)
- chmod は拡張 ACL を持つファイルに対して名前付きユーザーのエントリを削除し、基本の3エントリだけを残す動作になるため
- chmod によって所有グループのエントリが r-- になり、名前付きユーザーの実効権限は所有グループの権限を超えられない決まりのため
- chmod がデフォルト ACL 側のマスクを書き換え、その値がアクセス ACL 側のマスクへ随時反映される仕組みのため
解説
マスクエントリを持つファイルでは、パーミッションのグループ部分がマスクエントリに対応する。そのため権限ビットのグループ部分を絞る操作はマスクを絞る操作と同じ意味になり、名前付きユーザーのエントリはそのままでも実効権限だけが落ちる。マスクを持たないファイルではグループ部分が所有グループのエントリに対応する、という違いが混同しやすい。
他の選択肢が誤りである理由
- 「chmod は拡張 ACL を持つファイルに対して名前付きユーザーのエントリを削除し、基本の3エントリだけを残す動作になるため」権限ビットの変更で対応するエントリは書き換わるが、名前付きユーザーのエントリが削除されるわけではない。getfacl の出力に bob のエントリが残っていることとも整合しない。
- 「chmod によって所有グループのエントリが r-- になり、名前付きユーザーの実効権限は所有グループの権限を超えられない決まりのため」名前付きユーザーの実効権限の上限を決めるのはマスクであり、所有グループのエントリではない。所有グループのエントリ自身もマスクによって絞られる側にある。
- 「chmod がデフォルト ACL 側のマスクを書き換え、その値がアクセス ACL 側のマスクへ随時反映される仕組みのため」デフォルト ACL とアクセス ACL は別々に保持され、片方の変更がもう片方へ随時反映される仕組みは無い。デフォルト ACL が関わるのは以後作られるオブジェクトの初期値である。
続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。
登録なしで50問解く