LPIC-3 Security303-300 v3.0Weight 3Understand + Configure / Manage / Use

332.3 Resource Control：Processが「使える量」を制限する

332.1ではProcessのCapabilityやSystem Callを減らした。332.3では、同じProcessがCPU・Memory・Process数・File Descriptor等をどこまで消費できるかを制御する。

332.3の最終到達点
ulimitのSoft/Hard limitとPAM適用を理解・設定し、cgroupの階層・controller・limit・accounting・process associationを説明/管理できる。systemdのslice/scope/serviceをcgroupへ対応付け、UnitでCPU/Memory/Tasks/IO等を制限できる。

Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は末尾の問題へ。

公式要求：Understand/configure ulimits; understand cgroups including classes, limits and accounting; manage cgroups and process association; understand systemd slices/scopes/services; use systemd units to limit resources; awareness of cgmanager/libcgroup. Weight 3。

rlimit / ulimit1 Processとその子へ引き継がれる上限

cgroup複数Processを階層化してResourceを制御・計測

systemdService/Scope/Sliceをcgroupへ対応させて管理

学習接続：332.1のsystemd Hardeningでは「何を許すか」を制限した。332.3では同じUnitへ「どれだけ使えるか」を加える。

01 ulimit / PAM02 cgroup基礎03 Process Association04 slice / scope / service05 systemd Resource Limits

← 332.1 Host Hardening 332.3を開始 →

332.3 · 01/0501 ulimit / PAM

🔴 Understand / Configureulimit

ulimit：Soft limitとHard limitを「現在値と上限」に分ける

このページの到達点：ShellからResource Limitを確認・変更し、/etc/security/limits.confとpam_limits.soがLogin Sessionへどう適用されるか説明できる。

公式要求：Understand and configure ulimits. Partial list: ulimit, /etc/security/limits.conf, pam_limits.so.

2段階のLimit

Hard limit = そのSession/Processが上げられる上限 ↓ ceiling Soft limit = 現在実際に適用される値 ↓ Process resource usage Shellで設定したrlimit → 子Processへ継承

現在値を確認する

# 一覧 ulimit -a # open files (nofile) のSoft / Hard ulimit -Sn ulimit -Hn

-S

Soft limitを対象にする。

-H

Hard limitを対象にする。

-n

Open File Descriptor数（nofile）を対象にする。

$ ulimit -Sn 16384 $ ulimit -Hn 16384

Soft limitを変更する

# 現在Shellのnofile Soft limitを4096へ ulimit -S -n 4096 # 子Processでも継承値を確認 bash -c 'ulimit -Sn'

上げ下げの基本：一般UserはSoftをHard以下の範囲で変更できる。Hardをいったん下げると、そのSessionで一般Userが元より上へ戻せない場合があるため、実習ではSoft側を触る方が安全。

Login時の既定値はlimits.conf + PAM

# /etc/security/limits.conf の書式 # domain type item value alice soft nofile 4096 alice hard nofile 8192 @developers hard nproc 200

domain

User名、@group等の適用対象。

soft / hard

どちらのLimitを設定するか。

item

nofile、nproc、core等のResource。

pam_limits.so

PAM Session開始時にlimits.conf等を読み、Login SessionのResource Limitへ反映するModule。

既存Sessionには自動反映されない：limits.confはPAMを通る新しいLogin Session等で適用される。systemdのSystem Serviceは通常Login PAM Sessionではないため、後半のLimitNOFILE=等を使う。

EXAM DECISION

「誰のLimitを、いつ設定する？」で選ぶ

現在Shell → ulimit
Login Sessionの既定値 → limits.conf + pam_limits.so
systemd Service → UnitのResource/Limit Directive

← 全体像次のページ →

332.3 · 02/0502 cgroup基礎

🟡 Understandcgroup

cgroup：ProcessをGroup化し、Resourceを「制限・配分・計測」する

このページの到達点：cgroupのHierarchyとControllerを理解し、Limit・Weight・Accountingの違い、cgroup v1/v2、/sys/fs/cgroup/と/proc/cgroupsの役割を説明できる。

公式要求：Understand cgroups, including classes, limits and accounting. Partial list: /sys/fs/cgroup/, /proc/cgroups.

cgroupの中心

Processes ↓ Group化 cgroup hierarchy ↓ controller ├─ cpu → CPU配分/上限 ├─ memory → Memory使用量/上限 ├─ io → I/O配分/上限 └─ pids → Task数上限同じGroup単位で「制限」と「使用量Accounting」ができる

Limit / Maxこれ以上使わせない上限

Weight / Share競合時の相対的な配分

Accountingどれだけ使ったか計測

v1とv2を混同しない

	cgroup v1	cgroup v2
Hierarchy	Controllerごとに別Hierarchyを持てる	基本はUnifiedな1本のHierarchy
現在位置	複数行/Controller別になり得る	`0::/...`の形式
Mount	環境により複数Mount	通常`/sys/fs/cgroup/`

Kernelが持つControllerを確認

cat /proc/cgroups # cgroup v2なら利用可能Controllerも確認 cat /sys/fs/cgroup/cgroup.controllers # 自分のProcessがどこに属するか cat /proc/self/cgroup

#subsys_name hierarchy num_cgroups enabled cpu 0 ... 1 memory 0 ... 1 ... $ cat /proc/self/cgroup 0::/...

v2で/proc/cgroupsのhierarchyが0でも「無効」とは限らない：Unified v2 Hierarchyへ載っている場合がある。enabled、cgroup.controllers、Mount状態を合わせて見る。

公式の「classes」：試験ではCPU/Memory/IO/PID等のResource種類（controller）と、それぞれのLimit/Accountingを結び付けて理解するのが重要。名称だけの暗記にしない。

EXAM DECISION

cgroup = Processの階層 + Resource Controller

Processをまとめる → cgroup core
CPU/Memory等を制御する → controller
上限 → limit/max、相対配分 → weight、使用量 → accounting

← 前のページ次のページ →

332.3 · 03/0503 Process Association

🔴 Managecgroup association

Process Association：PIDをどのcgroupへ所属させるか管理する

このページの到達点：現在のProcess所属を確認し、cgroup.procsが「そのcgroupに属するPID一覧＋Process移動Interface」であることを理解する。systemd管理環境では直接書換えとUnit管理の境界も説明できる。

公式要求：Manage cgroups and process cgroup association.

Associationは「PID → Group」

PID 1200 ─┐ PID 1201 ─┼→ /sys/fs/cgroup/app.slice/demo/ PID 1202 ─┘ ↓ cgroup.procs 1200 1201 1202 Processがfork → Childは基本的にParentと同じcgroupから開始

まず現在位置を読む

echo $$ cat /proc/$$/cgroup # systemd環境ならHierarchyをTreeで確認 systemd-cgls

cgroup v2のLow-level Interface

# 代表的な仕組み（root権限・適切なDelegationが必要） mkdir /sys/fs/cgroup/demo # PID 1234をdemoへ移す printf '%s\n' 1234 > /sys/fs/cgroup/demo/cgroup.procs # 所属PIDを確認 cat /sys/fs/cgroup/demo/cgroup.procs

systemd管理Hostで無計画に直接操作しない：/sys/fs/cgroup/はKernel Interfaceだが、systemdがUnitとcgroup Treeを管理している環境では直接Directory/Processを操作すると管理状態と衝突し得る。Low-level動作を理解した後、通常はsystemd Unit/Scopeで管理する。

systemdでProcess Associationを確認する補助例

# 外から起動するCommandを一時Scopeへまとめる例 systemd-run --scope --unit=lpic303-demo.scope sleep 300 systemd-cgls --unit lpic303-demo.scope

systemd-runは公式Partial listではないため丸暗記対象にしない。ここでは「scopeを作るとProcessが対応cgroupへまとめられる」ことを目で確認する補助。

EXAM DECISION

Associationの決定語

現在所属 → /proc/PID/cgroup
cgroup内のPID / 移動Interface → cgroup.procs
systemd管理のTree → systemd-cgls

← 前のページ次のページ →

332.3 · 04/0504 systemd Units

🟡 Understand🔴 Use

systemd：slice / scope / serviceをcgroup Hierarchyとして読む

このページの到達点：slice・scope・serviceの違いを説明し、systemd-cglsで構造、systemd-cgtopでResource使用量を見る。

公式要求：Understand systemd slices, scopes and services. Partial list: systemd-cgls, systemd-cgtop.

Unit Typeと役割

-.slice ├─ system.slice ← System Service群をまとめるSlice │ ├─ ssh.service ← systemdが起動・管理するService │ └─ demo.service └─ user.slice └─ user-1000.slice └─ session-3.scope ← 外部で開始されたProcess群を追跡するScope

servicesystemdがProcessを起動し、Lifecycleを管理するUnit。例：sshd.service。

scopesystemd自身が起動したのではない既存Process群をUnitとして追跡する。Sessionやsystemd-run --scope等。

sliceservice/scope等を階層的にまとめ、まとめた単位へResource Policyを適用するUnit。

Structureを見る：systemd-cgls

systemd-cgls # 特定UnitのSubtree systemd-cgls --unit ssh.service

cgls = cgroup list/tree：「どのUnit/Processがどのcgroup階層にいるか」を見る。

Usageを見る：systemd-cgtop

systemd-cgtop

cgtop = Resource Usage：cgroup単位のTask数・CPU・Memory・I/O等をTop風に観測する。Accounting/Controllerの状態によって表示できる項目は変わる。

知りたい	Tool
Hierarchy / Process所属	`systemd-cgls`
Resource使用量	`systemd-cgtop`

EXAM DECISION

Sliceは「制限値」ではなくGroupingのUnit

service → Processを起動・管理
scope → 外部Process群を追跡
slice → Unit群を階層化しResource Policyをまとめる

← 前のページ次のページ →

332.3 · 05/0505 Resource Limits / Awareness

🔴 Use⚪ Awareness

systemd Resource Control：CPU / Memory / Tasks / IOをUnitへ設定する

このページの到達点：systemd UnitでResource上限・相対配分・rlimitを設定し、ulimitとcgroup制御の違いを説明できる。cgmanager/libcgroupはAwarenessで識別する。

公式要求：Use systemd units to limit system resources processes can consume. Awareness of cgmanager and libcgroup utilities.

同じUnitに2種類のLimitがある

demo.service ├─ rlimit系 │ └─ LimitNOFILE=4096 │ └─ cgroup Resource Control ├─ CPUQuota=20% / CPUWeight= ├─ MemoryHigh= / MemoryMax= ├─ TasksMax= └─ IOWeight=

UnitへResource制限を設定

[Unit] Description=LPIC303 Resource Control Demo [Service] Type=simple ExecStart=/usr/bin/sleep infinity CPUQuota=20% CPUWeight=100 MemoryHigh=128M MemoryMax=256M TasksMax=50 IOWeight=100 LimitNOFILE=4096

Directive	考え方
`CPUQuota=20%`	CPU時間の上限。20%は1 CPU相当の20%を基準に考える。
`CPUWeight=`	CPU競合時の相対配分。Hard Maxではない。
`MemoryHigh=`	超過時にReclaim/Pressureを強める主な制御点。即Hard Killの上限とは役割が違う。
`MemoryMax=`	Memory使用量のHard上限。
`TasksMax=`	Unit/cgroup内のTask数を制限。
`IOWeight=`	I/O競合時の相対Weight。
`LimitNOFILE=`	File Descriptorのrlimit。cgroup ControllerではなくProcess Limit。

設定後の確認

systemctl daemon-reload systemctl start lpic303-resource-demo.service systemctl show lpic303-resource-demo.service \ -p CPUQuotaPerSecUSec \ -p MemoryHigh -p MemoryMax \ -p TasksMax -p LimitNOFILE systemd-cgls --unit lpic303-resource-demo.service systemd-cgtop

ulimit -u / nproc と TasksMax=は同じではない：前者はrlimit/RLIMIT_NPROC側、後者はcgroup pids Controller側の制限。問題文が「Login/Userのrlimit」なのか「Unit/cgroup内のTask数」なのかを見る。

Awareness：cgmanager / libcgroup

cgmanager

cgroup管理を提供するDaemon/API系。LPI 332.3では存在・役割のAwarenessでよく、詳細操作を主教材にしない。

libcgroup

cgroup操作用Libraryと関連Utility群を提供するProject。公式332.3ではAwareness。

332.3 EXIT CHECK

Soft / Hard ulimitを区別し設定✓

limits.conf → pam_limits → Login Sessionの流れ✓

cgroupのcontroller / limit / weight / accountingを説明✓

PIDとcgroup associationを説明・管理✓

slice / scope / serviceを区別✓

cgls = 構造、cgtop = 使用量✓

systemd UnitでCPU/Memory/Tasks等を制限✓

監査基準：LPI 303-300 v3.0 Objective 332.3、Linux-PAM limits.conf/pam_limits、Linux Kernel cgroup v2、systemd resource-control/cgls documentation。Sample Unitはsystemd 257のsystemd-analyze verifyでSyntax確認。

332.3 COMPLETE

次は332.2 Host Intrusion Detectionへ

332.1：Host/Processが「できること」を減らした
332.3：Processが「使える量」を制限した
332.2：そのHostで「何が起きた・何が変わった」を検出する

← 前のページ Objective問題へ →

332.3 Resource Control · CHECKPOINTObjective末尾

Weight 3客観判定50 → 75 → 100%

332.3 Resource Control：学習直後にここで解く

本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。

合格条件： 50%は基礎選択式7問中6問以上、75%は選択肢なし再現5問中4問以上。75%到達から72時間後、専用実戦Bankから9問中8問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。

現在の到達度

選択式から開始

問題プール 30問小テーマ 4 実戦Bank 12問直近重複を抑制未出題優先

小テーマ別履歴問題を解くと正答率を表示

全体到達度を見る

Objective Check

JavaScriptが無効：このCheckpointの自動採点と進捗保存はJavaScript実行環境で利用してください。本文はそのまま閲覧できます。

100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当12問から出題する。各問はObjectiveの要求深度に合わせて、状況判断・設定/出力読解・近い選択肢の比較を行い、必要な分野では穴埋め・複数選択も使用する。誤答時は選択肢の違いまで確認する。

出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。

この問題の役割：Objective理解の客観Checkpoint。50%/75%はObjective理解の確認、100%は専用実戦Bankで状況判断・設定/出力読解・近い選択肢まで確認する。

← Objective本文の最後へ次の推奨Objectiveへ →

← 332.1 Host Hardening

全体進捗·Checkpoint

332.2 Host IDS →