امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 94
Linux Fundamentals برای Operator/Developer
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Linux Fundamentals برای Operator/Developer». می‌تواند برای «Linux Fundamentals برای Operator/Developer» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Linux Fundamentals برای Operator/Developer».
می‌تواند برای «Linux Fundamentals برای Operator/Developer» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «Linux Fundamentals برای Operator/Developer» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
1. پرسش عملیاتی فقط «پروسس اجراست؟» نیست
ممکن است یک Process در Linux وجود داشته باشد، اما هویت اجرا، دسترسی فایل، Working Directory، Environment، رفتار Signal، مسیر خروج، مالکیت Socket، وضعیت Supervisor یا سلامت برنامه درست فهمیده نشده باشد. مدل عملیاتی قابل اتکا باید از شواهد شروع شود، نه از حفظ‌کردن چند دستور.
خروجی اصلی درس Linux Service Runtime Evidence Record v1 است؛ در آن مشاهده‌ی مستقیم، استنباط، مجهولات و تصمیم عملیاتی محدود از هم جدا می‌مانند.
2. هویت Process بخشی از Runtime State است
هر Process با User و Group مشخص اجرا می‌شود. PID، UID، GID، گروه‌های تکمیلی، هویت Executable/Artifact و در صورت ارتباط، Capabilityها را ثبت کنید. «چه کسی برنامه را اجرا کرد» با «Process واقعاً با چه Credentialی اجرا می‌شود» یکی نیست.
نتیجه‌ی محدود باید فقط مرز هویتی مشاهده‌شده را ببندد: کدام Process، با کدام Credential، در زمان ثبت شواهد اجرا شده است.
3. UID/GID، Groupها و Capabilityها سؤال‌های متفاوتی را پاسخ می‌دهند
بخش مهمی از Permission Checkها بر Credentialهایی مانند effective UID، effective GID و supplementary groups تکیه دارد. Linux Capabilityها بخشی از امتیازهای سنتی Superuser را به واحدهای جدا تقسیم می‌کنند که می‌توانند مستقل فعال یا غیرفعال شوند.
پس Capability یک لایه‌ی شواهد جداست؛ نه معادل UID 0 و نه اثبات ایمن‌بودن Process. آن را جدا از Ownership و Mode ثبت کنید.
4. مالکیت و Mode فایل شواهد Runtime هستند
هنگام ساخت فایل، Owner و Permission Bitها به Credentialهای Process و Context ساخت وابسته‌اند. در حالت معمول و بدون Default ACL، Mode درخواستی توسط umask فیلتر می‌شود؛ رفتار Group در Parent Directory نیز ممکن است اثر داشته باشد.
برای Access Failure فوراً «با root اجرا کن» نتیجه نگیرید. ابتدا Identity، Path، Owner/Group، Mode، umask یا ACL مرتبط را مشخص کنید.
5. CWD و Environment ورودی رفتار برنامه‌اند
Relative Pathها از Working Directory Process تفسیر می‌شوند و بسیاری از برنامه‌ها Configuration را از Environment Variable می‌گیرند. ممکن است سرویس بالا بیاید اما به‌دلیل تفاوت CWD یا Environment با Shell تعاملی، فایل یا State Directory دیگری را استفاده کند.
فقط Environment Inputهای مرتبط با مسئله را ثبت کنید و Secretها را وارد Evidence Record نکنید.
6. Signal یک درخواست با Semantics مشخص است
Signalهای Linux رفتار پیش‌فرض مشخص دارند و بسیاری از آن‌ها را می‌توان Ignore یا Handle کرد. Process می‌تواند برای Signalهایی مثل SIGTERM Handler داشته باشد، اما SIGKILL قابل Catch، Block یا Ignore نیست.
این تفاوت عملیاتی مهم است: SIGTERM مدیریت‌شده می‌تواند شواهد Cleanup برنامه را ایجاد کند؛ SIGKILL نمی‌تواند Handler پاک‌سازی داخل برنامه را اجرا کند.
7. مجوز ارسال Signal یک مرز هویتی است
ارسال Signal از طریق kill(2) تابع Permission Rule است و بسته به PID می‌تواند Process یا Process Group را هدف بگیرد. در این درس فقط به Child Process همان Fixture محلی و disposable Signal ارسال می‌شود.
هویت Target و نتیجه‌ی مشاهده‌شده را ثبت کنید. این درس برای دورزدن Permission یا Signal دادن به Processهای دیگران نیست.
8. Exit Status و علت پایان باید تفسیر شوند
Normal Exit، پایان با Signal و Restart توسط Supervisor سه مشاهده‌ی متفاوت‌اند. ابتدا Return Status یا Signal Reason خام را حفظ کنید و سپس تفسیر انجام دهید.
Exit Code صفر می‌تواند موفقیت برنامه طبق قرارداد خودش را نشان دهد، اما به‌تنهایی Ready بودن، صحت State خارجی یا Recoverability آینده را اثبات نمی‌کند.
9. File و Socket هویت را به Resource متصل می‌کنند
سرویس معمولاً State File یا Socket دارد. Path، Owner/Group یا هویت Process، Mode مرتبط و این‌که Socket فقط روی Loopback یا Interface دیگری Bind شده است ثبت شوند.
Lab فقط از Loopback Socket و Temporary State Directory استفاده می‌کند تا شواهد کاملاً محلی و disposable باشند.
10. وضعیت Supervisor با سلامت برنامه یکی نیست
Supervisor می‌تواند Process را Start، Stop یا Restart کند و Exit Information را نگه دارد. systemd یک Supervisor رایج در Linux است، اما تعریف Linux یا تنها Supervisor ممکن نیست.
Active بودن Process یا Restart شدن آن، شواهد Controller است. Readiness یا Business Health به Observable جداگانه در سطح Application نیاز دارد.
11. Graceful Stop و Forced Termination چیزهای متفاوتی را اثبات می‌کنند
در Fixture پایه، SIGTERM به Handler می‌رسد و قبل از خروج Cleanup ثبت می‌شود. در Probe اجباری، SIGKILL Process را بدون اجرای آن Handler پایان می‌دهد.
نتیجه این نیست که SIGKILL همیشه «بد» است؛ نتیجه این است که SIGKILL نمی‌تواند اثبات کند Cleanup داخل Process به‌صورت Graceful اجرا شده است.
12. ساخت Linux Service Runtime Evidence Record v1
فیلدهای Process/Service، PID و UID:GID، Groups/Capabilities، CWD، Environment Inputهای مرتبط، Executable/Artifact، Files/Sockets، Start Evidence، Stop Signal، Exit Status/Reason، Supervisor Action، Application Health Evidence، Recovery Check، Unknowns و Bounded Decision را ثبت کنید.
هر نتیجه‌ی تعیین‌کننده باید به یک مشاهده‌ی قابل ردیابی وصل باشد. اگر شواهد تعیین‌کننده وجود ندارد، آن Claim باید OPEN بماند.
13. Failure عمدی باید Shortcutها را رد کند
Lab شامل CWD/Environment mismatch، Permission Boundary محدود، Forced Termination بدون Cleanup، umask تغییرکرده، Process در حال اجرا با Health Marker نامعتبر و یک حالت Missing Evidence است.
این Probeها Shortcutهایی مثل «در Shell من اجرا شد پس Path سرویس درست است»، «root مشکل Permission را حل می‌کند»، «Kill یعنی Graceful Stop» یا «Running یعنی Healthy» را می‌شکنند.
14. Lab اجرایی محلی و Transfer با Context تغییرکرده
Fixture محلی یک Child Process کوچک متعلق به User فعلی اجرا می‌کند، فقط داخل Temporary Directory می‌نویسد، فقط روی Loopback Bind می‌شود و SIGTERM مدیریت‌شده را با SIGKILL مقایسه می‌کند. سپس Caseهای ثابت، مدل شواهد را بدون دست‌زدن به System Serviceها تمرین می‌دهند.
در Transfer، State Path، هویت اعلام‌شده‌ی سرویس، umask و Graceful-Stop Delay تغییر می‌کند. Evidence Record را از شواهد جدید بازسازی کنید و Verdict پایه را کپی نکنید.
15. فقط همان Claim را ببندید که شواهد پشتیبانی می‌کند
Operator قابل اتکا یک مشاهده را به Verdict گسترده تبدیل نمی‌کند. Identity، Permission، Environment، مسیر Signal/Exit، رفتار Supervisor، Health و Recovery Evidence را تا زمانی که شواهد اجازه دهد جدا نگه دارید.
بسته‌شدن Linux Service Runtime Evidence Record v1 فقط Dimensions اعلام‌شده‌ی Fixture را اثبات می‌کند. Deployment Architecture، Full Security Posture، Observability Strategy و Production Readiness بیرون از Scope این درس می‌مانند مگر آن‌که مستقیماً شواهد داشته باشند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
OPS-001-S1 retrieval
State the bounded Linux operator model and one non-goal.
OPS-001-S2 application
Complete Linux Service Runtime Evidence Record v1 for a supplied local fixture using direct observations.
OPS-001-S3 diagnosis
Diagnose one CWD/environment, permission/umask, signal/exit, or running-versus-health failure without changing an unrelated layer.
OPS-001-S4 decision
Defend a bounded recovery conclusion against the shortcuts “root fixes permissions,” “SIGKILL proves cleanup,” and “running means healthy.”
OPS-001-S5 transfer
Rebuild the runtime evidence record for a changed state path, service identity, umask, and graceful-stop delay without copying baseline conclusions.
ملاک‌های ارزیابی (rubric)
A sufficient submission:
- preserves identity, permission/capability, CWD/environment, signal/exit, supervisor, health, and recovery boundaries;
- distinguishes direct observation from inference;
- explains SIGTERM versus SIGKILL without claiming every program handles SIGTERM gracefully;
- treats permission failures as scoped identity/resource evidence instead of defaulting to root;
- computes file-mode implications from explicit creation context rather than guessing;
- keeps process/supervisor state separate from application readiness/health;
- leaves unsupported claims OPEN;
- recomputes the changed-context transfer independently.
Critical failure occurs when the learner closes an operational claim without decisive evidence, uses happy-path process existence as the sole proof, or expands the conclusion into adjacent deployment/security/observability scope.
منابع و تازگی
مطالعهٔ موارد (case studies)
A disposable unprivileged fixture records identity, CWD/environment, file/socket, SIGTERM cleanup, exit, supervisor and health evidence separately.
A relative state path resolves under the wrong CWD; restarting repeatedly without checking CWD/environment is rejected.
A scoped ownership/mode mismatch denies state-file access; broad root execution is rejected as the default repair.
A second fixture changes declared service identity, state path, umask and stop delay, requiring a fresh evidence record.
تصاویر درس
فایل‌های آزمایشگاه
Purpose: observe a bounded Linux service runtime without modifying system services.
Safe boundary:
- run as the current unprivileged user;
- launch only the supplied child fixture;
- bind only to
127.0.0.1on an ephemeral port; - write only inside a temporary directory;
- send SIGTERM/SIGKILL only to the child PID created by the supplied observer;
- do not point the scripts at production processes, PIDs, services, or privileged accounts.
Run:
python run_checks.py
python observe_runtime.pyUse the raw observations to complete Linux Service Runtime Evidence Record v1. The scripts intentionally do not provide the final diagnosis.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)