اضافه‌شده در نسخه 250.

تنظیمات MountAPIVFS= و PrivateUsers= به‌ویژه در ترکیب با RootDirectory= مفید هستند. برای جزئیات، به بخش‌های زیر مراجعه کنید.

اگر RootDirectory=/RootImage= همراه با NotifyAccess= استفاده شوند، سوکت اطلاع‌رسانی به‌طور خودکار از میزبان در محیط ریشه متصل (mount) می‌شود تا اطمینان حاصل شود که رابط اطلاع‌رسانی می‌تواند به درستی کار کند.

توجه داشته باشید که سرویس‌هایی که از RootDirectory=/RootImage= استفاده می‌کنند، نمی‌توانند از طریق پروتکل‌های syslog یا journal در زیرساخت ثبت وقایع میزبان گزارش ثبت کنند، مگر اینکه سوکت‌های مربوطه از میزبان متصل شوند، به‌ویژه:

فایل os-release(5) میزبان برای سرویس (به صورت فقط‌خواندنی) در مسیر /run/host/os-release در دسترس قرار خواهد گرفت. این فایل در صورت راه‌اندازی مجدد نرم (soft reboot، مراجعه کنید به: systemd-soft-reboot.service(8))، در صورتی که سرویس برای بقا در برابر آن پیکربندی شده باشد، به‌طور خودکار به‌روزرسانی می‌شود.

مثال 1. اتصال سوکت‌های گزارش‌گیری به محیط ریشه

BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout

به جای مسیر دایرکتوری، می‌توان یک دایرکتوری نسخه‌بندی‌شده ".v/" را مشخص کرد؛ برای جزئیات به systemd.v(7) مراجعه کنید.

این گزینه فقط برای سرویس‌های سیستمی یا سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت PrivateUsers= به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

هنگامی که DevicePolicy= روی "closed" یا "strict" تنظیم شده باشد، یا روی "auto" تنظیم شده و DeviceAllow= تنظیم شده باشد، این تنظیم /dev/loop-control را با حالت rw، و "block-loop" و "block-blkext" را با حالت rwm به DeviceAllow= اضافه می‌کند. برای جزئیات درباره DevicePolicy= یا DeviceAllow= به systemd.resource-control(5) مراجعه کنید. همچنین PrivateDevices= در زیر را ببینید، زیرا ممکن است تنظیم DevicePolicy= را تغییر دهد.

واحدهایی که از RootImage= استفاده می‌کنند، به‌طور خودکار یک وابستگی After= روی systemd-udevd.service کسب می‌کنند.

فایل os-release(5) میزبان برای سرویس (به صورت فقط‌خواندنی) به عنوان /run/host/os-release در دسترس خواهد بود. این فایل در راه‌اندازی مجدد نرم (soft reboot، مراجعه کنید به: systemd-soft-reboot.service(8))، در صورتی که سرویس برای بقا در برابر آن پیکربندی شده باشد، به‌طور خودکار به‌روزرسانی می‌شود.

به جای مسیر ایمیج، می‌توان یک دایرکتوری نسخه‌بندی‌شده ".v/" را مشخص کرد؛ برای جزئیات به systemd.v(7) مراجعه کنید.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 233.

نام‌های معتبر پارتیشن از Discoverable Partitions Specification[1] پیروی می‌کنند: root، usr، home، srv، esp، xbootldr، tmp، var.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 247.

برای اطمینان از اینکه ایجاد رونوشت‌های زودگذر به صورت کارآمد انجام می‌شود، دایرکتوری ریشه یا ایمیج ریشه باید روی همان سیستم‌فایلی قرار داشته باشد که /var/lib/systemd/ephemeral-trees/ قرار دارد. هنگام استفاده از RootEphemeral= با دایرکتوری‌های ریشه، btrfs(5) باید به عنوان سیستم‌فایل استفاده شود و دایرکتوری ریشه در حالت ایده‌آل باید یک زیرحجم باشد که systemd بتواند برای ایجاد رونوشت زودگذر از آن snapshot بگیرد. برای ایمیج‌های ریشه، باید از سیستم‌فایلی با پشتیبانی از reflinkها استفاده شود تا رونوشت زودگذر کارآمد تضمین گردد.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 254.

اگر ایمیج دیسک شامل یک پارتیشن جداگانه /usr/ باشد، آن نیز ممکن است با Verity محافظت شود که در این صورت هش ریشه ممکن است از طریق ویژگی گسترش‌یافته "user.verity.usrhash" یا یک فایل .usrhash در کنار ایمیج دیسک پیکربندی شود. در حال حاضر گزینه‌ای برای پیکربندی مستقیم هش ریشه برای سیستم‌فایل /usr/ از طریق فایل واحد وجود ندارد.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 246.

اگر ایمیج دیسک شامل یک پارتیشن جداگانه /usr/ باشد، آن نیز ممکن است با Verity محافظت شود که در این صورت امضا برای هش ریشه ممکن است از طریق یک فایل .usrhash.p7s در کنار ایمیج دیسک پیکربندی شود. در حال حاضر گزینه‌ای برای پیکربندی مستقیم امضای هش ریشه برای /usr/ از طریق فایل واحد وجود ندارد.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 246.

این گزینه فقط برای ایمیج‌های دیسکی پشتیبانی می‌شود که شامل یک سیستم‌فایل منفرد، بدون جدول پارتیشن احاطه‌کننده هستند. ایمیج‌هایی که حاوی جدول پارتیشن GPT هستند باید در عوض هم سیستم‌فایل ریشه و هم داده‌های Verity منطبق را در همان ایمیج بگنجانند و از Discoverable Partitions Specification[1] پیروی کنند.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 246.

root=verity+signed+encrypted+unprotected+absent: \
        usr=verity+signed+encrypted+unprotected+absent: \
        home=encrypted+unprotected+absent: \
        srv=encrypted+unprotected+absent: \
        tmp=encrypted+unprotected+absent: \
        var=encrypted+unprotected+absent

خط‌مشی پیش‌فرض برای ExtensionImagePolicy= عبارت است از:

root=verity+signed+encrypted+unprotected+absent: \
        usr=verity+signed+encrypted+unprotected+absent

اضافه‌شده در نسخه 254.

به منظور امکان‌پذیر ساختن انتشار ایمن اتصالات در زمان اجرا، مسیر /run/systemd/propagate/ روی میزبان برای تنظیم اتصالات جدید استفاده خواهد شد، و مسیر /run/host/incoming/ در فضای نام خصوصی به عنوان یک مرحله میانی برای ذخیره آن‌ها قبل از انتقال به نقطه اتصال نهایی استفاده می‌شود.

اضافه‌شده در نسخه 233.

این گزینه هنگامی که LogNamespace= استفاده می‌شود، زمانی که MountAPIVFS=yes باشد، یا زمانی که PrivateDevices=yes در ترکیب با RootDirectory= یا RootImage= استفاده شود، به صورت ضمنی اعمال می‌گردد.

اضافه‌شده در نسخه 257.

اگر هسته از گزینه‌های اتصال hidepid= به ازای هر نقطه اتصال پشتیبانی نکند، این تنظیم بدون اثر باقی می‌ماند، و فرآیندهای واحد قادر خواهند بود به سایر فرآیندها دسترسی داشته و آن‌ها را ببینند گویی که این گزینه استفاده نشده است.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 247.

همانند ProtectProc= در بالا، این گزینه از طریق فضای نام اتصال سیستم‌فایل پیاده‌سازی شده است، و از این رو محدودیت‌های یکسانی اعمال می‌شود: فقط برای سرویس‌های سیستمی در دسترس است، انتشار اتصال به جدول اتصال میزبان را غیرفعال می‌کند، و به‌طور ضمنی MountAPIVFS= را فعال می‌نماید. همچنین، مانند ProtectProc=، این تنظیم در صورتی که هسته استفاده‌شده از گزینه اتصال "subset=" برای "procfs" پشتیبانی نکند، با ظرافت غیرفعال می‌شود.

اضافه‌شده در نسخه 247.

BindPaths= اتصالات bind معمولی قابل نوشتن ایجاد می‌کند (مگر اینکه اتصال سیستم‌فایل مبدا قبلاً به صورت فقط‌خواندنی علامت‌گذاری شده باشد)، در حالی که BindReadOnlyPaths= اتصالات bind فقط‌خواندنی ایجاد می‌کند. این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست اتصالات bind واحد اضافه می‌کند. اگر رشته خالی به هر یک از این دو گزینه اختصاص یابد، کل فهرست اتصالات bind تعریف‌شده قبل از این بازنشانی می‌شود. توجه داشته باشید که در این حالت، صرف‌نظر از اینکه کدام یک از دو تنظیم استفاده شده باشد، هم اتصالات فقط‌خواندنی و هم اتصالات معمولی bind بازنشانی می‌شوند.

استفاده از این گزینه مستلزم آن است که یک فضای نام اتصال برای واحد اختصاص داده شود، یعنی تأثیر PrivateMounts= را به همراه دارد (به زیر مراجعه کنید).

این گزینه به‌ویژه زمانی مفید است که از RootDirectory=/RootImage= استفاده شود. در این حالت مسیر مبدا به مسیری در سیستم‌فایل میزبان اشاره دارد، در حالی که مسیر مقصد به مسیری در زیر دایرکتوری ریشه واحد اشاره می‌کند.

توجه داشته باشید که دایرکتوری مقصد باید وجود داشته باشد یا systemd بتواند آن را ایجاد کند. بنابراین، استفاده از این گزینه‌ها برای نقاط اتصال تو‌در‌تو در زیر مسیرهای مشخص‌شده در InaccessiblePaths=، یا زیر /home/ و سایر دایرکتوری‌های محافظت‌شده در صورت مشخص شدن ProtectHome=yes امکان‌پذیر نیست. در عوض باید از TemporaryFileSystem= با ":ro" یا ProtectHome=tmpfs استفاده شود.

اضافه‌شده در نسخه 233.

گزینه‌های اتصال ممکن است به صورت یک فهرست تکی جداشده با ویرگول از گزینه‌ها تعریف شوند، که در این صورت به‌طور ضمنی بر روی پارتیشن ریشه روی ایمیج اعمال می‌شوند، یا مجموعه‌ای از دوتایی‌های جداشده با دونقطه از نام پارتیشن و گزینه‌های اتصال باشند. نام‌های معتبر پارتیشن و گزینه‌های معتبر اتصال همان مواردی هستند که برای تنظیم RootImageOptions= در بالا شرح داده شد.

هر تعریف اتصال ممکن است با پیشوند "-" همراه باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد نادیده گرفته می‌شود. آرگومان مبدا، مسیری به یک گره دستگاه بلوکی یا فایل معمولی است. اگر مبدا یا مقصد حاوی ":" باشد، باید به صورت "\:" گریزانده (escape) شود. گره دستگاه یا فایل ایمیج سیستم‌فایل باید از همان قوانینی پیروی کند که برای RootImage= مشخص شده است. هر اتصالی که با این گزینه ایجاد شود مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست.

این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست مسیرهای اتصال واحد اضافه می‌کند. اگر رشته خالی اختصاص یابد، کل فهرست مسیرهای اتصال که پیش از این تعریف شده‌اند بازنشانی می‌شود.

توجه داشته باشید که دایرکتوری مقصد باید وجود داشته باشد یا systemd بتواند آن را ایجاد کند. بنابراین، استفاده از این گزینه‌ها برای نقاط اتصال تو‌در‌تو در زیر مسیرهای مشخص‌شده در InaccessiblePaths=، یا زیر /home/ و سایر دایرکتوری‌های محافظت‌شده در صورت مشخص شدن ProtectHome=yes امکان‌پذیر نیست.

هنگامی که DevicePolicy= روی "closed" یا "strict" تنظیم شده باشد، یا روی "auto" تنظیم شده و DeviceAllow= تنظیم شده باشد، این تنظیم /dev/loop-control را با حالت rw، و "block-loop" و "block-blkext" را با حالت rwm به DeviceAllow= اضافه می‌کند. برای جزئیات درباره DevicePolicy= یا DeviceAllow= به systemd.resource-control(5) مراجعه کنید. همچنین PrivateDevices= در زیر را ببینید، زیرا ممکن است تنظیم DevicePolicy= را تغییر دهد.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 247.

یک OverlayFS فقط‌خواندنی بر روی سلسله‌مراتب‌های /usr/ و /opt/ برای ایمیج‌های sysext و سلسله‌مراتب /etc/ برای ایمیج‌های confext راه‌اندازی خواهد شد. ترتیبی که ایمیج‌ها فهرست می‌شوند ترتیبی را که overlay روی هم قرار می‌گیرد مشخص می‌کند: ایمیج‌هایی که از اول به آخر مشخص شده‌اند، منجر به لایه‌های overlayfs از پایین به بالا خواهند شد.

گزینه‌های اتصال ممکن است به عنوان یک فهرست تکی جداشده با ویرگول از گزینه‌ها تعریف شوند، که در این صورت به‌طور ضمنی بر روی پارتیشن ریشه روی ایمیج اعمال می‌شوند، یا مجموعه‌ای از دوتایی‌های جداشده با دونقطه از نام پارتیشن و گزینه‌های اتصال باشند. نام‌های معتبر پارتیشن و گزینه‌های اتصال همان مواردی هستند که برای تنظیم RootImageOptions= در بالا شرح داده شد.

هر تعریف اتصال ممکن است با پیشوند "-" همراه باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد نادیده گرفته می‌شود. آرگومان مبدا، مسیری به یک گره دستگاه بلوکی یا فایل معمولی است. اگر مسیر مبدا حاوی ":" باشد، باید به صورت "\:" گریزانده شود. گره دستگاه یا فایل ایمیج سیستم‌فایل باید از همان قوانینی پیروی کند که برای RootImage= مشخص شده است. هر اتصالی که با این گزینه ایجاد شود مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست.

این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست مسیرهای ایمیج واحد اضافه می‌کند. اگر رشته خالی اختصاص یابد، کل فهرست مسیرهای اتصال تعریف‌شده پیش از این بازنشانی می‌شود.

هر ایمیج sysext باید حامل یک فایل /usr/lib/extension-release.d/extension-release.IMAGE باشد در حالی که هر ایمیج confext باید حامل یک فایل /etc/extension-release.d/extension-release.IMAGE با فراداده‌های مناسب باشد که با RootImage=/RootDirectory= یا میزبان مطابقت دارد. ببینید: os-release(5). برای غیرفعال کردن بررسی ایمنی مبنی بر مطابقت نام فایل extension-release با نام فایل ایمیج، می‌توان گزینه اتصال x-systemd.relax-extension-release-check را اضافه کرد.

هنگامی که DevicePolicy= روی "closed" یا "strict" تنظیم شده باشد، یا روی "auto" تنظیم شده و DeviceAllow= تنظیم شده باشد، این تنظیم /dev/loop-control را با حالت rw، و "block-loop" و "block-blkext" را با حالت rwm به DeviceAllow= اضافه می‌کند. برای جزئیات درباره DevicePolicy= یا DeviceAllow= به systemd.resource-control(5) مراجعه کنید. همچنین PrivateDevices= در زیر را ببینید، زیرا ممکن است تنظیم DevicePolicy= را تغییر دهد.

به جای مسیر ایمیج، می‌توان یک دایرکتوری نسخه‌بندی‌شده ".v/" را مشخص کرد؛ برای جزئیات به systemd.v(7) مراجعه کنید.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 248.

یک OverlayFS فقط‌خواندنی بر روی سلسله‌مراتب‌های /usr/ و /opt/ برای ایمیج‌های sysext و سلسله‌مراتب /etc/ برای ایمیج‌های confext راه‌اندازی خواهد شد. ترتیبی که دایرکتوری‌ها فهرست می‌شوند ترتیبی را که overlay روی هم قرار می‌گیرد مشخص می‌کند: دایرکتوری‌هایی که از ابتدا تا انتها مشخص شده‌اند منجر به لایه‌های overlayfs از پایین به بالا خواهند شد.

هر دایرکتوری فهرست‌شده در ExtensionDirectories= ممکن است دارای پیشوند "-" باشد، که در این صورت اگر مسیر مبدا آن وجود نداشته باشد نادیده گرفته می‌شود. هر اتصالی که با این گزینه ایجاد شود مختص واحد است و در جدول اتصالات میزبان قابل مشاهده نیست.

این تنظیمات ممکن است بیش از یک بار استفاده شوند، هر استفاده به فهرست مسیرهای دایرکتوری واحد اضافه می‌کند. اگر رشته خالی اختصاص یابد، کل فهرست مسیرهای اتصال تعریف‌شده پیش از این بازنشانی می‌شود.

هر دایرکتوری sysext باید شامل یک فایل /usr/lib/extension-release.d/extension-release.IMAGE باشد در حالی که هر دایرکتوری confext باید حاوی یک فایل /etc/extension-release.d/extension-release.IMAGE با فراداده‌های مناسب باشد که با RootImage=/RootDirectory= یا میزبان مطابقت دارد. ببینید: os-release(5).

توجه داشته باشید که استفاده از واحدهای کاربر نیازمند پشتیبانی از overlayfs در فضاهای نام کاربری بدون امتیاز است که برای اولین بار در هسته نسخه 5.11 معرفی شد.

به جای مسیر دایرکتوری، می‌توان یک دایرکتوری نسخه‌بندی‌شده ".v/" مشخص کرد؛ برای جزئیات به systemd.v(7) مراجعه کنید.

این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت PrivateUsers= به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافه‌شده در نسخه 251.

توجه داشته باشید که این گزینه فقط محدودیت‌های ضعیفی را روی نحو نام کاربر/گروه اعمال می‌کند، اما در بسیاری از مواردی که نام‌های کاربر/گروه از قوانین زیر پیروی نمی‌کنند هشدارهایی ایجاد خواهد کرد: نام مشخص‌شده باید فقط شامل نویسه‌های a-z، A-Z، 0-9، "_" و "-" باشد، به جز نویسه اول که باید یکی از a-z، A-Z و "_" باشد (یعنی ارقام و "-" به عنوان نویسه اول مجاز نیستند). نام کاربر/گروه باید حداقل یک نویسه و حداکثر ۳۱ نویسه داشته باشد. این محدودیت‌ها به منظور جلوگیری از ابهام و اطمینان از سازگاری و قابل حمل بودن نام‌های کاربر/گروه و فایل‌های واحد در میان سیستم‌های لینوکسی اعمال شده‌اند. برای جزئیات بیشتر در مورد نام‌های پذیرفته‌شده و نام‌هایی که هشدار دریافت می‌کنند به User/Group Name Syntax[3] مراجعه کنید.

هنگامی که همراه با DynamicUser= استفاده می‌شود، نام کاربر/گروه مشخص‌شده به صورت پویا در زمان شروع به کار سرویس تخصیص داده شده و در زمان توقف سرویس آزاد می‌شود — مگر اینکه از قبل به صورت ایستا تخصیص داده شده باشد (به زیر مراجعه کنید). اگر از DynamicUser= استفاده نشود، کاربر و گروه مشخص‌شده باید حداکثر تا زمان شروع به کار سرویس به صورت ایستا در پایگاه‌داده کاربر ایجاد شده باشند، برای مثال با استفاده از امکانات sysusers.d(5) که در زمان بوت یا زمان نصب بسته اعمال می‌شود. اگر تا آن زمان کاربر وجود نداشته باشد، فراخوانی برنامه با شکست مواجه خواهد شد.

اگر تنظیم User= استفاده شود، فهرست گروه‌های تکمیلی (supplementary groups) از فهرست گروه‌های پیش‌فرض کاربر مشخص‌شده، همان‌طور که در پایگاه‌داده کاربر و گروه سیستم تعریف شده است مقداردهی اولیه می‌شود. گروه‌های اضافی را می‌توان از طریق تنظیم SupplementaryGroups= پیکربندی کرد (به زیر مراجعه کنید).

اضافه‌شده در نسخه 232.

اضافه‌شده در نسخه 255.

توجه داشته باشید که برای هر واحدی که از این گزینه استفاده می‌کند، یک فرآیند گرداننده نشست PAM به عنوان بخشی از واحد نگهداری می‌شود و تا زمانی که واحد فعال است باقی می‌ماند تا اطمینان حاصل شود که هنگام خاتمه واحد و در نتیجه نشست PAM، اقدامات مناسب انجام می‌شود. این فرآیند "(sd-pam)" نامیده می‌شود و یک فرآیند فرزند مستقیم فرآیند اصلی واحد است.

توجه داشته باشید که هنگامی که از این گزینه برای یک واحد استفاده می‌شود، بسیار محتمل است (بسته به پیکربندی PAM) که فرآیند اصلی واحد در زمان فعال‌سازی به واحد دامنه نشست (session scope unit) اختصاصی خود منتقل شود. بنابراین این فرآیند با دو واحد مرتبط خواهد بود: واحدی که در ابتدا از آن راه‌اندازی شده است (و برای آن PAMName= پیکربندی شده بود)، و واحد دامنه نشست. با این حال، هر فرآیند فرزند آن فرآیند فقط با واحد دامنه نشست مرتبط خواهد بود. این امر پیامدهایی در صورت استفاده در ترکیب با NotifyAccess=all دارد، زیرا این فرآیندهای فرزند نمی‌توانند از طریق پیام‌های اطلاع‌رسانی بر تغییرات در واحد اصلی تأثیر بگذارند. این پیام‌ها متعلق به واحد دامنه نشست و نه واحد اصلی در نظر گرفته می‌شوند. بنابراین توصیه نمی‌شود که از PAMName= در ترکیب با NotifyAccess=all استفاده شود.

از دستور capability در systemd-analyze(1) برای بازیابی فهرستی از قابلیت‌های تعریف‌شده در سیستم محلی استفاده کنید.

مثال: اگر یک واحد دارای موارد زیر باشد:

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C

آن‌گاه CAP_A، CAP_B و CAP_C تنظیم می‌شوند. اگر سطر دوم دارای پیشوند "~" باشد، به عنوان مثال:

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C

آن‌گاه تنها CAP_A تنظیم می‌شود.

مجموعه‌های قابلیت فراگیر در صورتی مفید هستند که بخواهید فرآیندی را به عنوان یک کاربر بدون امتیاز اجرا کنید اما همچنان به آن قابلیت‌هایی بدهید. توجه داشته باشید که در این حالت گزینه keep-caps به‌طور خودکار به SecureBits= اضافه می‌شود تا قابلیت‌ها در طول تغییر کاربر حفظ شوند. AmbientCapabilities= بر دستورات دارای پیشوند "+" تأثیری ندارد.

اضافه‌شده در نسخه 229.

توجه داشته باشید که این تنظیم فقط بر فرآیندهای خود واحد (یا هر فرآیندی که مستقیماً یا غیرمستقیم از آن‌ها ایجاد شده است) تأثیر می‌گذارد. این تنظیم بر فرآیندهایی که ممکن است به درخواست آن‌ها از طریق ابزارهایی مانند at(1)، crontab(1)، systemd-run(1) یا سرویس‌های دلخواه IPC فراخوانده شوند، تأثیری ندارد.

اضافه‌شده در نسخه 187.

اضافه‌شده در نسخه 209.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 210.

مقدار ممکن است با "-" پیشوندگذاری شود، که در این صورت تمام خطاها نادیده گرفته می‌شوند. یک مقدار خالی ممکن است برای لغو تخصیص‌های قبلی مشخص شود. این گزینه بر دستورات دارای پیشوند "+" تأثیری ندارد.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 218.

توجه داشته باشید که اکثر محدودیت‌های منابع فرآیند که با این گزینه‌ها پیکربندی شده‌اند به ازای هر فرآیند هستند، و فرآیندها ممکن است برای به دست آوردن مجموعه جدیدی از منابع که مستقل از فرآیند اصلی محاسبه می‌شوند فرآیند فرعی (fork) ایجاد کنند و بنابراین ممکن است از محدودیت‌های تعیین‌شده فرار کنند. همچنین توجه داشته باشید که LimitRSS= در لینوکس پیاده‌سازی نشده است و تنظیم آن هیچ اثری ندارد. اغلب توصیه می‌شود که کنترل‌های منابع فهرست‌شده در systemd.resource-control(5) را بر این محدودیت‌های به ازای هر فرآیند ترجیح دهید، زیرا آن‌ها بر سرویس‌ها به عنوان یک کل اعمال می‌شوند، ممکن است به صورت پویا در زمان اجرا تغییر یابند، و عموماً گویاتر هستند. به عنوان مثال، MemoryMax= یک جایگزین بسیار قدرتمندتر (و کاربردی) برای LimitRSS= است.

توجه داشته باشید که LimitNPROC= تعداد فرآیندهای مربوط به یک UID (واقعی) را محدود می‌کند و نه تعداد فرآیندهای شروع‌شده (fork شده) توسط سرویس را. بنابراین این محدودیت برای همه فرآیندهایی که تحت همان UID اجرا می‌شوند تجمیعی است. لطفاً توجه داشته باشید که اگر سرویس به عنوان root اجرا شود (و امتیازات خود را کاهش ندهد)، LimitNPROC= اعمال نخواهد شد. به دلیل این محدودیت‌ها، TasksMax= (به systemd.resource-control(5) مراجعه کنید) معمولاً انتخابی بهتر از LimitNPROC= است.

محدودیت‌های منابعی که به صراحت برای یک واحد پیکربندی نشده‌اند، پیش‌فرض روی مقدار پیکربندی‌شده در گزینه‌های مختلف DefaultLimitCPU=، DefaultLimitFSIZE= و غیره موجود در systemd-system.conf(5) قرار می‌گیرند، و – در صورت عدم پیکربندی در آنجا – پیش‌فرض‌های هسته یا پیش‌فرض‌های کاربر-محور که توسط سیستم‌عامل تعریف شده است (مورد دوم فقط برای سرویس‌های کاربری، به زیر مراجعه کنید).

برای واحدهای سیستمی این محدودیت‌های منابع ممکن است آزادانه انتخاب شوند. هنگامی که این تنظیمات در یک سرویس کاربری پیکربندی می‌شوند (یعنی سرویسی که توسط نمونه کاربر-محور مدیر سرویس اجرا می‌شود) نمی‌توان از آن‌ها برای افزایش محدودیت‌ها به بالاتر از مقادیر تعیین‌شده برای خود مدیر کاربر در زمان اولین فراخوانی استفاده کرد، زیرا مدیر سرویس کاربر معمولاً فاقد امتیازات لازم برای انجام این کار است. در چارچوب کاربری، این گزینه‌های پیکربندی فقط برای کاهش محدودیت‌های دریافت‌شده یا افزایش محدودیت نرم به حداکثر محدودیت سخت همان‌طور که برای کاربر پیکربندی شده است مفید هستند. برای افزایش بیشتر محدودیت‌های کاربر، سازوکارهای پیکربندی موجود در بین سیستم‌های عامل متفاوت است، اما معمولاً نیازمند امتیازات مدیریتی است. در بیشتر موارد می‌توان محدودیت‌های منابع بالاتر به ازای هر کاربر را از طریق PAM یا با تنظیم محدودیت‌ها روی سرویس سیستمی که مدیر سرویس کاربر را کپسوله‌سازی می‌کند، یعنی نمونه user@.service کاربر، پیکربندی کرد. پس از اعمال چنین تغییراتی، حتماً مدیر سرویس کاربر را مجدداً راه‌اندازی کنید.

جدول 1. دستورالعمل‌های محدودیت منابع، معادل‌های آن‌ها در دستور ulimit شل و واحد مورد استفاده

مثال 2. افزودن صفحات DAX به فیلتر تخلیه حافظه

CoredumpFilter=default private-dax shared-dax

اضافه‌شده در نسخه 246.

اضافه‌شده در نسخه 235.

از تنظیم OOMPolicy= در واحدهای سرویس برای پیکربندی نحوه واکنش مدیر سرویس به پایان دادن به یک فرآیند سرویس توسط قاتل OOM هسته یا systemd-oomd استفاده کنید. برای جزئیات به systemd.service(5) مراجعه کنید.

اضافه‌شده در نسخه 209.

اضافه‌شده در نسخه 243.

اضافه‌شده در نسخه 243.

توجه داشته باشید که اگر ProtectSystem= روی "strict" تنظیم شده باشد و PrivateTmp= فعال باشد، آن‌گاه /tmp/ و /var/tmp/ قابل نوشتن خواهند بود.

اضافه‌شده در نسخه 214.

تنظیم این گزینه روی "yes" عمدتاً معادل تنظیم این سه دایرکتوری در InaccessiblePaths= است. مشابهاً، "read-only" عمدتاً معادل ReadOnlyPaths= است، و "tmpfs" عمدتاً معادل TemporaryFileSystem= با ":ro" است.

توصیه می‌شود این تنظیم برای تمام سرویس‌های با اجرای طولانی‌مدت (به‌ویژه سرویس‌های متصل به شبکه) فعال شود تا اطمینان حاصل گردد که نمی‌توانند به داده‌های خصوصی کاربر دسترسی پیدا کنند، مگر اینکه سرویس‌ها واقعاً به دسترسی به داده‌های خصوصی کاربر نیاز داشته باشند. این تنظیم در صورت تنظیم DynamicUser= به صورت ضمنی اعمال می‌شود. این تنظیم نمی‌تواند در تمام موارد محافظت را تضمین کند. به طور کلی همان محدودیت‌های ReadOnlyPaths= را دارد، به زیر مراجعه کنید.

توجه داشته باشید که اگر دایرکتوری‌های خانگی در مکانی غیراستاندارد، یعنی خارج از سلسله‌مراتب‌های فهرست‌شده در بالا قرار گیرند، این تنظیم هیچ محافظتی ارائه نمی‌دهد.

این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت PrivateUsers= به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافه‌شده در نسخه 214.

اگر DynamicUser= استفاده شود و اگر نسخه هسته از اتصالات با نگاشت شناسه (id-mapped mounts)[7] پشتیبانی کند، دایرکتوری‌های مشخص‌شده متعلق به "nobody" در فضای نام میزبان خواهند بود و به UID/GID سرویس در فضای نام خودش نگاشت می‌شوند (و تحت مالکیت آن قرار می‌گیرند). برای سازگاری با گذشته، دایرکتوری‌های موجود ایجادشده بدون اتصالات با نگاشت شناسه بدون دستکاری باقی خواهند ماند.

جدول 2. ایجاد خودکار دایرکتوری و متغیرهای محیطی

در مورد
RuntimeDirectory= درونی‌ترین زیردایرکتوری‌ها در هنگام متوقف شدن واحد حذف می‌شوند. در این حالت در صورتی که RuntimeDirectoryPreserve= روی restart یا yes پیکربندی شده باشد، حفظ دایرکتوری‌های مشخص‌شده امکان‌پذیر است (به زیر مراجعه کنید). دایرکتوری‌های مشخص‌شده با StateDirectory=، CacheDirectory=، LogsDirectory=، ConfigurationDirectory= هنگام توقف واحد حذف نمی‌شوند.

به جز در مورد ConfigurationDirectory=، درونی‌ترین دایرکتوری‌های مشخص‌شده تحت مالکیت کاربر و گروه مشخص‌شده در User= و Group= خواهند بود. اگر دایرکتوری‌های مشخص‌شده از قبل وجود داشته باشند و کاربر یا گروه مالک آن‌ها با موارد پیکربندی‌شده مطابقت نداشته باشد، مالکیت تمام فایل‌ها و دایرکتوری‌های زیر دایرکتوری‌های مشخص‌شده و همچنین خود دایرکتوری‌ها به صورت بازگشتی تغییر می‌کند تا با موارد پیکربندی‌شده مطابقت یابد. به عنوان یک بهینه‌سازی، اگر دایرکتوری‌های مشخص‌شده از قبل متعلق به کاربر و گروه مناسب باشند، فایل‌ها و دایرکتوری‌های زیرین آن‌ها دست‌نخورده باقی می‌مانند، حتی اگر با آنچه درخواست شده مطابقت نداشته باشند. حالت دسترسی درونی‌ترین دایرکتوری‌های مشخص‌شده مطابق با آنچه در RuntimeDirectoryMode=، StateDirectoryMode=، CacheDirectoryMode=، LogsDirectoryMode= و ConfigurationDirectoryMode= مشخص شده است تنظیم خواهد شد.

این گزینه‌ها به صورت ضمنی BindPaths= را برای مسیرهای مشخص‌شده فعال می‌کنند. هنگامی که با RootDirectory= یا RootImage= ترکیب شوند، این مسیرها همیشه روی میزبان قرار دارند و از آنجا به درون فضای نام سیستم‌فایل واحد متصل می‌شوند.

اگر از DynamicUser= استفاده شود، منطق CacheDirectory=، LogsDirectory= و StateDirectory= کمی تغییر می‌کند: دایرکتوری‌ها به ترتیب در زیر /var/cache/private، /var/log/private و /var/lib/private ایجاد می‌شوند که دایرکتوری‌های میزبانی هستند که برای کاربران بدون امتیاز غیرقابل دسترسی شده‌اند، که این امر تضمین می‌کند دسترسی به این دایرکتوری‌ها از طریق بازیافت شناسه کاربر پویا حاصل نمی‌شود. پیوندهای نمادین (symlinks) برای پنهان کردن این تفاوت در رفتار ایجاد می‌شوند. از این رو، چه از دید میزبان و چه از درون واحد، دایرکتوری‌های مربوطه همیشه مستقیماً در زیر /var/cache، /var/log و /var/lib ظاهر می‌شوند.

از RuntimeDirectory= برای مدیریت یک یا چند دایرکتوری زمان اجرا برای واحد و پیوند دادن طول عمر آن‌ها به زمان اجرای دیمون استفاده کنید. این گزینه به‌ویژه برای دیمون‌های بدون امتیازی که به دلیل فقدان امتیاز نمی‌توانند دایرکتوری‌های زمان اجرا در /run/ ایجاد کنند، و برای اطمینان از اینکه دایرکتوری زمان اجرا پس از استفاده به‌طور خودکار پاک‌سازی می‌شود، مفید است. برای دایرکتوری‌های زمان اجرایی که به پیکربندی پیچیده‌تر یا متفاوت یا تضمین‌های طول عمر نیاز دارند، لطفاً استفاده از tmpfiles.d(5) را در نظر بگیرید.

گزینه‌های RuntimeDirectory=، StateDirectory=، CacheDirectory= و LogsDirectory= به صورت اختیاری از دو پارامتر دیگر، جداشده با ":" پشتیبانی می‌کنند. پارامتر دوم به عنوان یک مسیر مقصد تفسیر خواهد شد که به عنوان یک پیوند نمادین (symlink) به دایرکتوری ایجاد می‌شود. پیوندهای نمادین پس از تنظیم هر یک از گزینه‌های BindPaths= یا TemporaryFileSystem= ایجاد می‌شوند تا پیوند نمادین زودگذر امکان‌پذیر شود. یک منبع یکسان می‌تواند چندین پیوند نمادین داشته باشد، با استفاده از همان پارامتر اول یکسان اما یک پارامتر دوم متفاوت. پارامتر سوم یک فیلد پرچم است و از نسخه 257 می‌تواند مقدار ro را بگیرد تا دایرکتوری را برای سرویس فقط‌خواندنی کند. این مورد برای ConfigurationDirectory= نیز پشتیبانی می‌شود. اگر چندین پیوند نمادین تنظیم شده باشد، در صورتی که حداقل یکی به صورت فقط‌خواندنی پیکربندی شده باشد، دایرکتوری فقط‌خواندنی خواهد بود. برای ارسال یک پرچم بدون پیوند نمادین مقصد، پارامتر دوم می‌تواند خالی باشد، به عنوان مثال:

ConfigurationDirectory=foo::ro

دایرکتوری‌های تعریف‌شده توسط این گزینه‌ها همیشه در زیر مسیرهای استاندارد مورد استفاده توسط systemd (/var/، /run/، /etc/ و غیره) ایجاد می‌شوند. اگر سرویس به دایرکتوری‌هایی در مکانی متفاوت نیاز دارد، باید از سازوکار دیگری برای ایجاد آن‌ها استفاده شود.

ابزار tmpfiles.d(5) عملکردی را ارائه می‌دهد که با این گزینه‌ها همپوشانی دارد. استفاده از این گزینه‌ها توصیه می‌شود زیرا طول عمر دایرکتوری‌ها مستقیماً به طول عمر واحد گره خورده است، و نیازی به اطمینان از اجرای پیکربندی tmpfiles.d قبل از شروع واحد نیست.

برای حذف هر یک از دایرکتوری‌های ایجادشده توسط این تنظیمات، از دستور systemctl clean ... روی واحدهای مربوطه استفاده کنید، برای جزئیات به systemctl(1) مراجعه کنید.

مثال: اگر یک واحد سرویس سیستمی دارای موارد زیر باشد:

RuntimeDirectory=foo/bar baz

مدیر سرویس مسیر /run/foo (اگر وجود نداشته باشد)، /run/foo/bar و /run/baz را ایجاد می‌کند. دایرکتوری‌های /run/foo/bar و /run/baz به جز /run/foo تحت مالکیت کاربر و گروه مشخص‌شده در User= و Group= هستند و با توقف سرویس حذف می‌شوند.

مثال: اگر یک واحد سرویس سیستمی دارای موارد زیر باشد:

RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc

آن‌گاه متغیر محیطی "RUNTIME_DIRECTORY" با مقدار "/run/foo/bar" و "STATE_DIRECTORY" با مقدار "/var/lib/aaa/bbb:/var/lib/ccc" تنظیم می‌شود.

مثال: اگر یک واحد سرویس سیستمی دارای موارد زیر باشد:

RuntimeDirectory=foo:bar foo:baz

مدیر سرویس /run/foo (اگر وجود نداشته باشد) و /run/bar به همراه /run/baz را به عنوان پیوندهای نمادین به /run/foo ایجاد می‌کند.

اضافه‌شده در نسخه 211.

اضافه‌شده در نسخه 234.

اضافه‌شده در نسخه 235.

اضافه‌شده در نسخه 244.

مسیرهای فهرست‌شده در ReadWritePaths= از درون فضای نام با همان حالت‌های دسترسی مانند بیرون از آن قابل دسترسی هستند. مسیرهای فهرست‌شده در ReadOnlyPaths= فقط برای خواندن قابل دسترسی هستند و نوشتن در آن‌ها رد خواهد شد حتی اگر کنترل‌های دسترسی معمول فایل این اجازه را بدهند. برای ارائه زیردایرکتوری‌های قابل نوشتن در داخل دایرکتوری‌های فقط‌خواندنی، ReadWritePaths= را در داخل ReadOnlyPaths= تودرتو قرار دهید. اگر از ProtectSystem=strict استفاده می‌شود، از ReadWritePaths= برای قرار دادن مسیرهای خاص در فهرست مجاز برای دسترسی نوشتن استفاده کنید. توجه داشته باشید که نمی‌توان از ReadWritePaths= برای به دست آوردن دسترسی نوشتن به سیستم‌فایلی که ابربلوک (superblock) آن فقط‌خواندنی متصل شده است استفاده کرد. در لینوکس، برای هر نقطه اتصال، دسترسی نوشتن تنها در صورتی اعطا می‌شود که خود نقطه اتصال و ابربلوک سیستم‌فایل پشتیبان آن به صورت فقط‌خواندنی علامت‌گذاری نشده باشند. ReadWritePaths= فقط اولی را کنترل می‌کند نه دومی را، بنابراین یک ابربلوک سیستم‌فایل فقط‌خواندنی همچنان محافظت‌شده باقی می‌ماند.

مسیرهای فهرست‌شده در InaccessiblePaths= برای فرآیندهای درون فضای نام به همراه همه موارد زیر آن‌ها در سلسله‌مراتب سیستم‌فایل غیرقابل دسترسی خواهند شد. این ممکن است محدودکننده‌تر از حد مورد نظر باشد، زیرا امکان تودرتو کردن ReadWritePaths=، ReadOnlyPaths=، BindPaths= یا BindReadOnlyPaths= در داخل آن وجود ندارد. برای گزینه‌ای انعطاف‌پذیرتر، به TemporaryFileSystem= مراجعه کنید.

محتوای موجود در مسیرهای فهرست‌شده در NoExecPaths= قابل اجرا نیست حتی اگر کنترل‌های دسترسی معمول فایل این اجازه را بدهند. برای ارائه محتوای قابل اجرا در دایرکتوری‌های غیرقابل اجرا، ExecPaths= را در داخل NoExecPaths= تودرتو قرار دهید.

مسیرهای غیردایرکتوری نیز ممکن است مشخص شوند. این گزینه‌ها ممکن است بیش از یک بار مشخص شوند، که در این صورت تمام مسیرهای فهرست‌شده دسترسی محدودی از درون فضای نام خواهند داشت. اگر رشته خالی به این گزینه اختصاص یابد، فهرست مربوطه بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود.

مسیرها در ReadWritePaths=، ReadOnlyPaths=، InaccessiblePaths=، ExecPaths= و NoExecPaths= ممکن است دارای پیشوند "-" باشند، که در این صورت در صورت عدم وجود نادیده گرفته می‌شوند. اگر با "+" پیشوندگذاری شوند، مسیرها نسبت به دایرکتوری ریشه واحد، همان‌طور که با RootDirectory=/RootImage= پیکربندی شده است، به جای نسبت به دایرکتوری ریشه میزبان در نظر گرفته می‌شوند (به بالا مراجعه کنید). هنگام ترکیب "-" و "+" روی یک مسیر یکسان، حتماً ابتدا "-" و سپس "+" را مشخص کنید.

توجه داشته باشید که این تنظیمات انتشار اتصالات از فرآیندهای واحد به میزبان را قطع خواهد کرد. این بدان معناست که این تنظیم ممکن است برای سرویس‌هایی که باید بتوانند نقاط اتصال را در فضای نام اصلی اتصال نصب کنند، استفاده نشود. برای ReadWritePaths= و ReadOnlyPaths=، انتشار در جهت دیگر تحت تأثیر قرار نمی‌گیرد، یعنی اتصالات ایجادشده در میزبان عموماً در فضای نام فرآیندهای واحد ظاهر می‌شوند، و اتصالات حذف‌شده در میزبان نیز در آنجا ناپدید می‌شوند. به ویژه، توجه داشته باشید که انتشار اتصال از میزبان به واحد منجر به ایجاد اتصالات بدون تغییر در فضای نام واحد می‌شود، یعنی اتصالات قابل نوشتنی که در میزبان ظاهر می‌شوند در فضای نام واحد نیز قابل نوشتن خواهند بود، حتی زمانی که در زیر مسیری که با ReadOnlyPaths= علامت‌گذاری شده منتشر شوند! بنابراین محدود کردن دسترسی با این گزینه‌ها به اتصالات فرعی دایرکتوری که بعداً ایجاد می‌شوند تعمیم نمی‌یابد. این بدان معناست که قفل امنیتی ارائه‌شده توسط این تنظیم کامل نیست و محافظت تمام و کمال ارائه نمی‌دهد.

توجه داشته باشید که اثر این تنظیمات ممکن است توسط فرآیندهای دارای امتیاز باطل شود. بنابراین برای راه‌اندازی یک محیط ایزوله مؤثر برای یک واحد، توصیه می‌شود این تنظیمات را با CapabilityBoundingSet=~CAP_SYS_ADMIN یا SystemCallFilter=~@mount ترکیب کنید.

لطفاً هنگام اعمال این گزینه‌ها روی سیستم‌های فایل API (فهرستی از آن‌ها در MountAPIVFS= یافت می‌شود) بسیار محتاط باشید، زیرا ممکن است برای عملکردهای اساسی سیستم مورد نیاز باشند. علاوه بر این، /run/ برای راه‌اندازی فضای نام اتصال و انتشار باید قابل نوشتن باشد.

مثال ساده فهرست مجاز با استفاده از این دستورالعمل‌ها:

[Service]
ReadOnlyPaths=/
ReadWritePaths=/var /run
InaccessiblePaths=-/lost+found
NoExecPaths=/
ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64

این گزینه‌ها فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس هستند که در این صورت PrivateUsers= به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافه‌شده در نسخه 231.

این گزینه برای پنهان کردن فایل‌ها یا دایرکتوری‌هایی که به فرآیندهای فراخوانده‌شده توسط واحد مربوط نیستند مفید است، در حالی که فایل‌ها یا دایرکتوری‌های ضروری همچنان می‌توانند با ترکیب با BindPaths= یا BindReadOnlyPaths= قابل دسترسی باشند:

مثال: اگر یک واحد دارای موارد زیر باشد:

TemporaryFileSystem=/var:ro
BindReadOnlyPaths=/var/lib/systemd

آن‌گاه فرآیندهای فراخوانده‌شده توسط واحد نمی‌توانند هیچ فایل یا دایرکتوری زیر /var/ را ببینند به جز /var/lib/systemd یا محتویات آن.

این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت PrivateUsers= به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافه‌شده در نسخه 238.

این تنظیم برای ایمن‌سازی دسترسی به فایل‌های موقت فرآیند مفید است، اما اشتراک‌گذاری بین فرآیندها از طریق /tmp/ یا /var/tmp/ را غیرممکن می‌سازد. اگر روی "disconnected" تنظیم نشده باشد، اجرای دو یا چند واحد در یک فضای نام خصوصی مشترک /tmp/ و /var/tmp/ با استفاده از دستورالعمل JoinsNamespaceOf= امکان‌پذیر است؛ برای جزئیات به systemd.unit(5) مراجعه کنید. این تنظیم در صورت تنظیم DynamicUser= به صورت ضمنی اعمال می‌شود. برای این تنظیم، همان محدودیت‌های مربوط به انتشار اتصالات و امتیازات مانند ReadOnlyPaths= و فراخوانی‌های مرتبط اعمال می‌شود، به بالا مراجعه کنید. در صورت تنظیم روی "true" (بر خلاف "disconnected")، این گزینه اثر جانبی افزودن وابستگی‌های Requires= و After= روی تمام واحدهای اتصال لازم برای دسترسی به /tmp/ و /var/tmp/ روی میزبان را دارد. علاوه بر این، یک ترتیب‌بندی ضمنی After= روی systemd-tmpfiles-setup.service(8) اضافه می‌شود.

توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام اتصال در دسترس نباشند)، و واحد باید به‌گونه‌ای نوشته شود که فقط به این تنظیم برای امنیت تکیه نکند.

این گزینه فقط برای سرویس‌های سیستمی یا برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند در دسترس است که در این صورت PrivateUsers= به‌طور ضمنی فعال می‌شود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

فعال کردن این گزینه یک فیلتر فراخوانی سیستمی برای مسدود کردن فراخوانیهای سطح پایین I/O که در مجموعه @raw-io گروهبندی شدهاند نصب میکند، CAP_MKNOD و CAP_SYS_RAWIO را از مجموعه محدودکننده قابلیت برای واحد حذف میکند و DevicePolicy=closed را تنظیم میکند (برای جزئیات به systemd.resource-control(5) مراجعه کنید). توجه داشته باشید که استفاده از این تنظیم، انتشار اتصالات از سرویس به میزبان را قطع میکند (انتشار در جهت مخالف همچنان کار میکند). این بدان معناست که این تنظیم ممکن است برای سرویسهایی که باید بتوانند نقاط اتصال را در فضای نام اصلی اتصال نصب کنند، استفاده نشود. مسیر جدید /dev/ به صورت فقطخواندنی و با پرچم 'noexec' متصل خواهد شد. مورد دوم ممکن است برنامههای قدیمی را که سعی میکنند با استفاده از mmap(2) روی /dev/zero به جای استفاده از MAP_ANON حافظه قابل اجرا راهاندازی کنند، با مشکل مواجه کند. برای این تنظیم همان محدودیتهای مربوط به انتشار اتصال و امتیازات مانند ReadOnlyPaths= و فراخوانیهای مرتبط اعمال میشود، به بالا مراجعه کنید.

توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام اتصال در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت تکیه نکند.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

هنگامی که دسترسی به برخی دستگاهها (و نه همه) باید امکانپذیر باشد، ممکن است به جای آن از تنظیم DeviceAllow= استفاده شود. به systemd.resource-control(5) مراجعه کنید.

اضافهشده در نسخه 209.

توجه داشته باشید که پیادهسازی این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام شبکه در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت متکی نباشد.

هنگامی که این گزینه فعال باشد، PrivateMounts= به صورت ضمنی فعال میشود مگر اینکه صریحاً غیرفعال شده باشد، و /sys مجدداً متصل میشود تا با فضای نام شبکه جدید مرتبط گردد.

هنگامی که این گزینه در یک واحد سوکت استفاده شود، هر سوکتی که از طرف این واحد متصل (bind) شود درون یک فضای نام شبکه خصوصی متصل خواهد شد. این ممکن است با JoinsNamespaceOf= ترکیب شود تا روی سوکتهای داخل فضاهای نام شبکه سایر سرویسها گوش فرا داده شود.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

هنگامی که این گزینه فعال باشد، PrivateMounts= به صورت ضمنی فعال میشود مگر اینکه صریحاً غیرفعال شده باشد، و /sys مجدداً متصل میشود تا با فضای نام شبکه جدید مرتبط گردد.

هنگامی که این گزینه در یک واحد سوکت استفاده شود، هر سوکتی که از طرف این واحد bind شود، درون فضای نام شبکه مشخصشده متصل خواهد شد.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 242.

توجه داشته باشید که فضاسازی نام IPC بر سوکتهای AF_UNIX که رایجترین شکل IPC در لینوکس هستند، تأثیری ندارد. در عوض، سوکتهای AF_UNIX در سیستمفایل مشمول فضاسازی نام اتصال، و سوکتهای موجود در فضای نام انتزاعی مشمول فضاسازی نام شبکه هستند. فضاسازی نام IPC فقط بر System V IPC (که عمدتاً قدیمی و موروثی است) و همچنین صفهای پیام POSIX (که سوکتهای AF_UNIX/SOCK_SEQPACKET معمولاً جایگزین بهتری برای آنها هستند) اثر دارد. فضاسازی نام IPC همچنین بر حافظه اشتراکی POSIX (که مشمول فضاسازی نام اتصال است) نیز تأثیری ندارد. برای جزئیات به ipc_namespaces(7) مراجعه کنید.

توجه داشته باشید که پیادهسازی این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام IPC در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت متکی نباشد.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 248.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 248.

توجه داشته باشید که این عملکرد ممکن است در دسترس نباشد، برای مثال اگر KSM در هسته غیرفعال باشد، یا هسته از کنترل KSM در سطح فرآیند از طریق prctl(2) پشتیبانی نکند.

اضافهشده در نسخه 254.

گزینه PrivatePIDs= فقط برای واحدهای سرویس پشتیبانی میشود. این تنظیم با Type=forking پشتیبانی نمیشود زیرا در صورت پایان یافتن فرآیند init، هسته تمام فرآیندهای موجود در فضای نام PID را از بین خواهد برد.

اگر هسته از فضاهای نام PID پشتیبانی نکند، این تنظیم نادیده گرفته خواهد شد.

توجه داشته باشید که سرویسهای کاربری بدون امتیاز (یعنی سرویسی که توسط نمونه کاربر-محور مدیر سرویس اجرا میشود) در صورتی که /proc/ پوشش داده شده باشد (یعنی /proc/kmsg با tmpfs پوشانده شده باشد همانطور که systemd-nspawn(1) انجام میدهد) با PrivatePIDs=yes شکست خواهند خورد. این به دلیل محدودیت هسته است که به فضاهای نام کاربری بدون امتیاز اجازه نمیدهد نمونهای با محدودیت کمتر از /proc/ را متصل کنند.

اضافهشده در نسخه 257.

اگر پارامتر "identity" باشد، فضاسازی نام کاربر با یک نگاشت همانی برای اولین 65536 شناسه UID/GID راهاندازی میشود. هر UID/GID بالاتر از 65536 به ترتیب به کاربر و گروه "nobody" نگاشت خواهد شد. در حالی که این حالت جداسازی UID/GID را ارائه نمیدهد، زیرا همه UID/GIDها به صورت یکسان انتخاب شدهاند، جداسازی قابلیتهای فرآیند را فراهم میکند و از این رو اغلب اگر فضاسازی نام کاربری مناسب با نقشههای UID متمایز مناسب نباشد، یک انتخاب خوب است.

اگر این حالت فعال باشد، تمام فرآیندهای واحد بدون امتیاز در فضای نام کاربری میزبان اجرا میشوند (صرفنظر از اینکه کاربر/گروه خود واحد "root" باشد یا خیر). به طور خاص این بدان معناست که فرآیند دارای صفر قابلیت فرآیند در فضای نام کاربری میزبان خواهد بود، اما قابلیتهای کامل را در فضای نام کاربری سرویس خواهد داشت. تنظیماتی مانند CapabilityBoundingSet= فقط بر دومی تأثیر میگذارد، و هیچ راهی برای به دست آوردن قابلیتهای اضافی در فضای نام کاربری میزبان وجود ندارد.

هنگامی که این تنظیم توسط یک نمونه کاربر-محور مدیر سرویس راهاندازی میشود، نگاشت کاربر و گروه "root" به خودش حذف میشود (مگر اینکه مدیر کاربر root باشد). علاوه بر این، در حالت مدیر نمونه کاربر-محور، فضای نام کاربر قبل از بیشتر فضاهای نام دیگر راهاندازی میشود. این بدان معناست که ترکیب PrivateUsers=true با سایر فضاهای نام، امکان استفاده از ویژگیهایی را که معمولاً توسط نمونههای کاربر-محور مدیر سرویس پشتیبانی نمیشوند فراهم میکند.

این تنظیم بهویژه در ترکیب با RootDirectory=/RootImage= مفید است، زیرا نیاز به همگامسازی پایگاههای داده کاربر و گروه در دایرکتوری ریشه و روی میزبان را کاهش میدهد، زیرا تنها کاربران و گروههایی که باید مطابقت داشته باشند "root"، "nobody" و کاربر و گروه خود واحد هستند.

توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام کاربری در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت تکیه نکند.

اضافهشده در نسخه 232.

توجه داشته باشید که اجرای این تنظیم ممکن است غیرممکن باشد (مثلاً اگر فضاهای نام UTS در دسترس نباشند)، و واحد باید بهگونهای نوشته شود که فقط به این تنظیم برای امنیت متکی نباشد.

توجه داشته باشید که هنگامی که این گزینه برای یک سرویس فعال است، تغییرات نام میزبان دیگر از سیستم به سرویس منتشر نمیشود، بنابراین برای سرویسهایی که باید تغییرات نام میزبان سیستم را به صورت پویا متوجه شوند مناسب نیست.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 242.

توصیه میشود این گزینه برای اکثر سرویسهایی که نیازی به تغییر ساعت یا بررسی وضعیت آن ندارند روشن شود.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 245.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 232.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 232.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 244.

به جز مدیران کانتینر، هیچ سرویسی نباید به دسترسی نوشتن به سلسلهمراتبهای گروههای کنترلی نیاز داشته باشد؛ از این رو توصیه میشود برای اکثر سرویسها ProtectControlGroups= روی true یا "strict" تنظیم شود. برای این تنظیم، همان محدودیتهای مربوط به انتشار اتصالات و امتیازات مانند ReadOnlyPaths= و تنظیمات مرتبط اعمال میشود، به بالا مراجعه کنید.

این گزینه فقط برای سرویسهای سیستمی در دسترس است و برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند پشتیبانی نمیشود.

اضافهشده در نسخه 232.

به طور پیشفرض، هیچ محدودیتی اعمال نمیشود و تمام خانوادههای آدرس برای فرآیندها قابل دسترسی هستند. اگر رشته خالی اختصاص داده شود، هرگونه تغییر قبلی در محدودیت خانواده آدرس لغو میشود. این تنظیم بر دستورات دارای پیشوند "+" تأثیری ندارد.

از این گزینه برای محدود کردن قرار گرفتن فرآیندها در معرض دسترسی از راه دور، به ویژه از طریق پروتکلهای شبکه غیرمتعارف و حساس مانند AF_PACKET استفاده کنید. توجه داشته باشید که در بیشتر موارد، خانواده آدرس محلی AF_UNIX باید در فهرست مجاز پیکربندیشده گنجانده شود زیرا مکرراً برای ارتباطات محلی، از جمله برای ثبت لاگ syslog(2) استفاده میشود.

توجه داشته باشید که این گزینه فقط دسترسی به فراخوانی سیستمی socket(2) را محدود میکند. سوکتهایی که به روشهای دیگر به فرآیند منتقل میشوند (مثلاً با استفاده از فعالسازی سوکت با واحدهای سوکت، به systemd.socket(5) مراجعه کنید) تحت تأثیر قرار نمیگیرند. همچنین سوکتهای ایجادشده با socketpair() (که سوکتهای متصل AF_UNIX ایجاد میکند) یا توابع io_uring(7) تحت تأثیر قرار نمیگیرند. بنابراین توصیه میشود این تنظیم را با SystemCallFilter=@service ترکیب کنید تا فقط به زیرمجموعه محدودی از فراخوانیهای سیستمی اجازه داده شود.

توجه داشته باشید که این گزینه محدود به برخی ABIها، به ویژه x86-64 است، اما در حال حاضر روی معماریهای 32 بیتی x86، s390، s390x، mips، mips-le، ppc، ppc-le، ppc64 یا ppc64-le هیچ اثری ندارد و نادیده گرفته میشود. در سیستمهایی که از چندین ABI پشتیبانی میکنند (مانند x86/x86-64) توصیه میشود ABIهای جایگزین را برای سرویسها غیرفعال کنید تا نتوان از آنها برای دور زدن محدودیتهای این گزینه استفاده کرد. به طور خاص، توصیه میشود این گزینه را با SystemCallArchitectures=native یا مشابه آن ترکیب نمایید.

اضافهشده در نسخه 211.

اگر هر دو نوع این گزینه را مشخص کنید (یعنی فهرست مجاز و فهرست مسدود)، اولین موردی که با آن مواجه میشوید اولویت خواهد داشت و اقدام پیشفرض را دیکته میکند (اجازه دسترسی به سیستمفایل یا رد آن). سپس رخدادهای بعدی این گزینه بسته به نوع آن و اقدام پیشفرض، سیستمهای فایل فهرستشده را از مجموعه سیستمهای فایل محدودشده اضافه یا حذف میکنند.

مثال: اگر یک واحد دارای موارد زیر باشد:

RestrictFileSystems=ext4 tmpfs
RestrictFileSystems=ext2 ext4

آنگاه دسترسی به ext4، tmpfs و ext2 مجاز است و دسترسی به سایر سیستمهای فایل رد میشود.

مثال: اگر یک واحد دارای موارد زیر باشد:

RestrictFileSystems=ext4 tmpfs
RestrictFileSystems=~ext4

آنگاه فقط دسترسی به tmpfs مجاز است.

مثال: اگر یک واحد دارای موارد زیر باشد:

RestrictFileSystems=~ext4 tmpfs
RestrictFileSystems=ext4

آنگاه فقط دسترسی به tmpfs رد میشود.

از آنجا که تعداد سیستمهای فایل ممکن زیاد است، مجموعههای از پیش تعریفشدهای از سیستمهای فایل ارائه شدهاند. یک مجموعه با نویسه "@" شروع میشود که نام مجموعه به دنبال آن میآید.

جدول 3. مجموعههای سیستمفایل از پیش تعریفشده کنونی

از دستور
filesystems در systemd-analyze(1) برای بازیابی فهرستی از سیستمهای فایل تعریفشده در سیستم محلی استفاده کنید.

توجه داشته باشید که این تنظیم ممکن است در برخی سیستمها پشتیبانی نشود (مثلاً اگر قلاب LSM eBPF در هسته زیربنایی فعال نباشد یا اگر از سلسلهمراتب گروه کنترلی یکپارچه استفاده نشود). در این حالت این تنظیم هیچ اثری ندارد.

این گزینه را نمیتوان با پیشوندگذاری "+" به مسیر اجرایی در واحد سرویس دور زد، زیرا برای کل گروه کنترلی اعمال میشود.

اضافهشده در نسخه 250.

مثال: اگر یک واحد دارای موارد زیر باشد:

RestrictNamespaces=cgroup ipc
RestrictNamespaces=cgroup net

آنگاه cgroup، ipc و net تنظیم میشوند. اگر سطر دوم دارای پیشوند "~" باشد، به عنوان مثال:

RestrictNamespaces=cgroup ipc
RestrictNamespaces=~cgroup net

آنگاه تنها ipc تنظیم میشود.

اضافهشده در نسخه 233.

اضافهشده در نسخه 235.

اضافهشده در نسخه 231.

اضافهشده در نسخه 231.

اضافهشده در نسخه 242.

این گزینه فقط برای سرویسهای سیستمی در دسترس است و برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند پشتیبانی نمیشود.

اضافهشده در نسخه 232.

هنگامی که روشن شود، این گزینه سه عملیات را برای هر فرآیند فراخواندهشده اجرا میکند: یک فضای نام جدید CLONE_NEWNS ایجاد میشود، پس از آن تمام اتصالات موجود مجدداً به MS_SLAVE متصل میشوند تا انتشار از فرآیندهای واحد به میزبان غیرفعال شود (اما انتشار در جهت مخالف همچنان برقرار باقی میماند). در نهایت، اتصالات دوباره به حالت انتشار پیکربندیشده با MountFlags= متصل میشوند، به زیر مراجعه کنید.

فضاهای نام سیستمفایل به صورت جداگانه برای هر فرآیندی که توسط مدیر سرویس fork شده است راهاندازی میشوند. اتصالات برقرارشده در فضای نام فرآیند ایجادشده توسط ExecStartPre= بنابراین به محض خروج آن فرآیند بهطور خودکار پاکسازی میشوند و برای فرآیندهای بعدی fork شده برای ExecStart= در دسترس نخواهند بود (و موارد مشابه برای دستورات مختلف دیگری که برای واحدها پیکربندی شدهاند نیز صدق میکند). مشابهاً، JoinsNamespaceOf= اجازه اشتراک فضاهای نام اتصال هسته بین واحدها را نمیدهد، بلکه فقط امکان اشتراکگذاری دایرکتوریهای /tmp/ و /var/tmp/ را فراهم میکند.

سایر تنظیمات واحد فضای نام سیستمفایل — PrivateTmp=، PrivateDevices=، ProtectSystem=، ProtectHome=، ReadOnlyPaths=، InaccessiblePaths=، ReadWritePaths=، BindPaths=، BindReadOnlyPaths= و غیره — نیز فضاسازی نام سیستمفایل را به روشی معادل با این گزینه فعال میکنند. از این رو در درجه اول در صورتی مفید است که صریحاً این رفتار درخواست شود اگر هیچ یک از تنظیمات دیگر استفاده نشده باشد.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

اضافهشده در نسخه 239.

این تنظیم فقط تنظیم انتشار نهایی را که بر روی تمام نقاط اتصال فضای نام سیستمفایل ایجادشده برای هر فرآیند این واحد مؤثر است کنترل میکند. سایر تنظیمات واحد فضاسازی نام سیستمفایل (به بحث در PrivateMounts= در بالا مراجعه کنید) با تغییر تنظیم انتشار تمام نقاط اتصال در فضای نام سیستمفایل واحد به slave در ابتدا، انتشار اتصال و جداسازی را از فرآیندهای واحد به سمت میزبان به صورت ضمنی غیرفعال میکنند. تنظیم این گزینه روی shared در آن حالت انتشار را دوباره برقرار نمیکند.

اگر تنظیم نشده باشد – اما فضاهای نام سیستمفایل از طریق یک تنظیم واحد دیگر فضای نام سیستمفایل فعال شده باشد – انتشار اتصال shared استفاده میشود، اما – همانطور که ذکر شد – از آنجا که ابتدا slave اعمال میشود، انتشار از فرآیندهای واحد به میزبان همچنان خاموش است.

استفاده از انتشار اتصال private برای واحدها توصیه نمیشود، زیرا این بدان معناست که اتصالات موقت (مانند رسانههای جداشدنی) میزبان در فرآیندهای fork شده متصل و بنابراین برای همیشه مشغول باقی میمانند، زیرا رویدادهای انتشار جداسازی توسط فضای نام سیستمفایل واحد دریافت نخواهند شد.

معمولاً بهتر است این تنظیم را بدون تغییر باقی بگذارید و به جای آن از گزینههای سطح بالاتر فضاسازی نام سیستمفایل، به ویژه PrivateMounts= استفاده کنید، به بالا مراجعه کنید.

این گزینه فقط برای سرویسهای سیستمی یا برای سرویسهایی که در نمونههای کاربر-محور مدیر سرویس اجرا میشوند در دسترس است که در این صورت PrivateUsers= بهطور ضمنی فعال میشود (نیازمند فعال بودن پشتیبانی از فضاهای نام کاربری بدون امتیاز در هسته از طریق sysctl با نام "kernel.unprivileged_userns_clone=" است).

دستورات با پیشوند "+" مشمول فیلتر کردن نیستند. فراخوانی‌های سیستمی execve()، exit()، exit_group()، getrlimit()، rt_sigreturn()، sigreturn() و فراخوانی‌های سیستمی برای پرس‌وجوی زمان و خواب (sleep) به صورت ضمنی در فهرست مجاز قرار دارند و نیازی به فهرست کردن صریح آن‌ها نیست.

اقدام پیش‌فرض هنگام رد شدن یک فراخوانی سیستمی، خاتمه دادن به فرآیندها با سیگنال SIGSYS است. این مورد را می‌توان با استفاده از SystemCallErrorNumber= تغییر داد، به زیر مراجعه کنید. علاوه بر این، فراخوانی‌های سیستمی و گروه‌های فراخوانی سیستمیِ موجود در فهرست مسدود ممکن است به صورت اختیاری با یک دونقطه (":") و یک آرگومان در همان قالب SystemCallErrorNumber= پسوندگذاری شوند تا هنگام انجام فراخوانی سیستمی منطبق، این اقدام انجام شود. این بر اقدام مشخص‌شده در SystemCallErrorNumber= اولویت دارد.

این ویژگی از رابط‌های حالت محاسباتی امن ۲ هسته ('seccomp filtering') استفاده می‌کند و برای اعمال یک محیط ایزوله کمینه مفید است.

توجه داشته باشید که در سیستم‌هایی که از چندین ABI پشتیبانی می‌کنند (مانند x86/x86-64) توصیه می‌شود ABIهای جایگزین را برای سرویس‌ها غیرفعال کنید تا نتوان از آن‌ها برای دور زدن محدودیت‌های این گزینه استفاده کرد. به طور خاص، توصیه می‌شود این گزینه را با SystemCallArchitectures=native یا مشابه آن ترکیب نمایید.

توجه داشته باشید که فیلترهای دقیق فراخوانی سیستمی ممکن است بر مسیرهای کد اجرا و مدیریت خطای فراخوانی سرویس تأثیر بگذارند. به طور خاص، دسترسی به فراخوانی سیستمی execve() برای اجرای باینری سرویس لازم است — در صورت مسدود شدن آن، فراخوانی سرویس لزوماً با شکست مواجه خواهد شد. همچنین اگر اجرای باینری سرویس به دلایلی با شکست مواجه شود (مثلاً: فایل اجرایی سرویس وجود نداشته باشد)، منطق مدیریت خطا ممکن است برای پردازش و ثبت صحیح این خطا به دسترسی به مجموعه‌ای از فراخوانی‌های سیستمی اضافی نیاز داشته باشد. ممکن است لازم باشد موقتاً فیلترهای فراخوانی سیستمی را غیرفعال کنید تا امکان اشکال‌زدایی چنین خطاهایی فراهم شود.

اگر هر دو نوع این گزینه را مشخص کنید (یعنی فهرست مجاز و فهرست مسدود)، اولین موردی که با آن مواجه می‌شوید اولویت خواهد داشت و اقدام پیش‌فرض را دیکته می‌کند (خاتمه یا تأیید یک فراخوانی سیستمی). سپس رخدادهای بعدی این گزینه بسته به نوع آن و اقدام پیش‌فرض، فراخوانی‌های سیستمی فهرست‌شده را از مجموعه فراخوانی‌های سیستمی فیلترشده اضافه یا حذف می‌کنند. (به عنوان مثال، اگر با یک قانون فهرست مجاز برای read() و write() شروع کرده باشید، و بلافاصله پس از آن یک قانون فهرست مسدود برای write() اضافه کنید، آن‌گاه write() از مجموعه حذف خواهد شد.)

از آنجا که تعداد فراخوانی‌های سیستمی ممکن زیاد است، گروه‌های از پیش تعریف‌شده‌ای از فراخوانی‌های سیستمی ارائه شده است. یک گروه با نویسه "@" شروع می‌شود که نام مجموعه به دنبال آن می‌آید.

جدول &4. &مجموعه‌های فراخوانی سیستمی از پیش تعریف‌شده کنونی

توجه داشته باشید که با اضافه شدن فراخوانی‌های سیستمی جدید به هسته، ممکن است فراخوانی‌های سیستمی بیشتری به گروه‌های بالا اضافه شوند. محتویات مجموعه‌ها نیز ممکن است بین نسخه‌های systemd تغییر کند. علاوه بر این، فهرست فراخوانی‌های سیستمی به نسخه هسته و معماری که systemd برای آن کامپایل شده است بستگی دارد. از
systemd-analyze syscall-filter برای فهرست کردن لیست واقعی فراخوانی‌های سیستمی در هر فیلتر استفاده کنید.

به طور کلی، قرار دادن فراخوانی‌های سیستمی در فهرست مجاز (به جای فهرست مسدود) حالت عملکرد ایمن‌تری است. توصیه می‌شود فهرست‌های مجاز فراخوانی سیستمی برای تمام سرویس‌های سیستمی با اجرای طولانی اعمال شود. به طور خاص، خطوط زیر یک انتخاب پایه نسبتاً ایمن برای اکثر سرویس‌های سیستمی هستند:

[Service]
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

توجه داشته باشید که فراخوانی‌های سیستمی مختلف هسته به صورت تکراری تعریف شده‌اند: چندین فراخوانی سیستمی برای اجرای یک عملیات یکسان وجود دارد. به عنوان مثال، فراخوانی سیستمی pidfd_send_signal() ممکن است برای اجرای عملیات مشابه آنچه می‌توان با فراخوانی سیستمی قدیمی‌تر kill() انجام داد استفاده شود، از این رو مسدود کردن دومی بدون اولی فقط محافظت ضعیفی ارائه می‌دهد. از آنجا که فراخوانی‌های سیستمی جدید به طور منظم با پیشرفت توسعه به هسته اضافه می‌شوند، جامع نگه داشتن فهرست‌های مسدود فراخوانی سیستمی نیاز به کار مداوم دارد. بنابراین توصیه می‌شود به جای آن از فهرست مجاز استفاده شود، که این مزیت را دارد که فراخوانی‌های سیستمی جدید به طور پیش‌فرض به صورت ضمنی مسدود می‌شوند تا زمانی که فهرست مجاز به‌روزرسانی شود.

همچنین توجه داشته باشید که تعدادی از فراخوانی‌های سیستمی برای کارکرد پیونددهنده پویا (dynamic linker) باید قابل دسترسی باشند. پیونددهنده پویا برای اجرای اکثر برنامه‌های معمولی مورد نیاز است (به ویژه: تمام باینری‌های پویای ELF، که روشی است که اکثر توزیع‌ها برنامه‌های بسته‌بندی‌شده را می‌سازند). این بدان معناست که مسدود کردن این فراخوانی‌های سیستمی (شامل open()، openat() یا mmap()) اکثر برنامه‌هایی را که معمولاً با توزیع‌های عمومی ارائه می‌شوند، غیرقابل استفاده خواهد کرد.

توصیه می‌شود گزینه‌های مربوط به فضاسازی نام سیستم‌فایل را با SystemCallFilter=~@mount ترکیب کنید، تا فرآیندهای واحد از باطل کردن نگاشت‌ها منع شوند. به طور خاص این‌ها گزینه‌های زیر هستند: PrivateTmp=، PrivateDevices=، ProtectSystem=، ProtectHome=، ProtectKernelTunables=، ProtectControlGroups=، ProtectKernelLogs=، ProtectClock=، ReadOnlyPaths=، InaccessiblePaths= و ReadWritePaths=.

اضافه‌شده در نسخه 187.

اضافه‌شده در نسخه 209.

اگر از این تنظیم استفاده شود، فرآیندهای این واحد فقط مجاز خواهند بود فراخوانی‌های سیستمی بومی و فراخوانی‌های سیستمی معماری‌های مشخص‌شده را فراخوانی کنند. برای اهداف این گزینه، معماری x32 شامل فراخوانی‌های سیستمی x86-64 در نظر گرفته می‌شود. با این حال، این تنظیم همچنان هدف خود را، همان‌طور که در زیر توضیح داده شده است، در x32 برآورده می‌کند.

فیلتر کردن فراخوانی سیستمی در همه معماری‌ها به یک اندازه مؤثر نیست. برای مثال، در x86 فیلتر کردن فراخوانی‌های مربوط به سوکت شبکه به دلیل محدودیت‌های ABI امکان‌پذیر نیست — محدودیتی که البته x86-64 ندارد. در سیستم‌هایی که همزمان از چندین ABI پشتیبانی می‌کنند — مانند x86/x86-64 — از این رو توصیه می‌شود مجموعه معماری‌های مجاز فراخوانی سیستمی را محدود کنید تا ABIهای ثانویه نتوانند برای دور زدن محدودیت‌های اعمال‌شده بر ABI بومی سیستم استفاده شوند. به ویژه، تنظیم SystemCallArchitectures=native یک انتخاب خوب برای غیرفعال کردن ABIهای غیربومی است.

معماری‌های فراخوانی سیستمی ممکن است در سراسر سیستم از طریق گزینه SystemCallArchitectures= در پیکربندی سراسری نیز محدود شوند. برای جزئیات به systemd-system.conf(5) مراجعه کنید.

اضافه‌شده در نسخه 209.

اضافه‌شده در نسخه 247.

این گزینه ممکن است بیش از یک بار مشخص شود، که در این صورت تمام متغیرهای فهرست‌شده تنظیم خواهند شد. اگر یک متغیر دو بار فهرست شود، تنظیم بعدی تنظیم قبلی را بازنویسی خواهد کرد. اگر رشته خالی به این گزینه اختصاص یابد، فهرست متغیرهای محیطی بازنشانی می‌شود و تمام تخصیص‌های قبلی بی‌اثر خواهند بود.

نام متغیرها می‌تواند شامل حروف ASCII، ارقام و نویسه زیرخط باشد. نام متغیر نمی‌تواند خالی باشد یا با یک رقم شروع شود. در مقادیر متغیر، بیشتر نویسه‌ها مجاز هستند، اما نویسه‌های غیرقابل چاپ در حال حاضر رد می‌شوند.

مثال:

Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"

سه متغیر "VAR1"، "VAR2"، "VAR3" را با مقادیر "word1 word2"، "word3"، "$word 5 6" ایجاد می‌کند.

برای جزئیات درباره متغیرهای محیطی به environ(7) مراجعه کنید.

توجه داشته باشید که متغیرهای محیطی برای انتقال داده‌های محرمانه (مانند گذرواژه‌ها، داده‌های کلید و غیره) به فرآیندهای سرویس مناسب نیستند. متغیرهای محیطی تنظیم‌شده برای یک واحد از طریق D-Bus IPC در دسترس کلاینت‌های بدون امتیاز قرار می‌گیرند، و عموماً به عنوان داده‌هایی که نیاز به حفاظت دارند درک نمی‌شوند. علاوه بر این، متغیرهای محیطی در درخت فرآیندها، از جمله در مرزهای امنیتی (مانند فایل‌های اجرایی setuid/setgid) منتشر می‌شوند، و از این رو ممکن است به فرآیندهایی که نباید به داده‌های محرمانه دسترسی داشته باشند نشت کنند. از LoadCredential=، LoadCredentialEncrypted= یا SetCredentialEncrypted= (به زیر مراجعه کنید) برای ارسال ایمن داده‌ها به فرآیندهای واحد استفاده کنید.

در فایل، یک مقدار بدون نقل‌قول بعد از "=" با همان قوانین گریز با بک‌اسلش مانند متن بدون نقل‌قول شل POSIX[12] تجزیه می‌شود، اما بر خلاف شل، فضای خالی داخلی حفظ می‌شود و نقل‌قول‌ها پس از اولین نویسه غیرفضای‌خالی حفظ می‌گردند. فاصله‌های خالی ابتدا و انتهای سطر (فاصله، تب، carriage return) دور ریخته می‌شوند، اما فاصله‌های خالی داخلی درون سطر به همان صورت حفظ می‌شوند. سطری که با یک بک‌اسلش پایان می‌یابد به سطر بعدی ادامه می‌یابد، در حالی که خود خط جدید دور ریخته می‌شود. یک بک‌اسلش "\" به دنبال هر نویسه‌ای غیر از خط جدید، نویسه بعدی را حفظ می‌کند، به طوری که "\\" تبدیل به مقدار "\" می‌شود.

در فایل، یک مقدار نقل‌قول‌شده با "'" بعد از "=" می‌تواند چندین سطر را در بر بگیرد و شامل هر نویسه‌ای به همان صورت به جز نقل‌قول تکی باشد، مانند متن با نقل‌قول تکی شل POSIX[13]. هیچ توالی گریز با بک‌اسلش شناسایی نمی‌شود. فاصله‌های خالی ابتدا و انتها در خارج از نقل‌قول تکی دور ریخته می‌شوند.

در فایل، یک مقدار نقل‌قول‌شده با بعد از "=" می‌تواند چندین سطر را در بر بگیرد، و همان توالی‌های گریز مانند متن با نقل‌قول دوتایی شل POSIX[14] شناسایی می‌شوند. بک‌اسلش ("\") به دنبال هر یک از " آن نویسه را حفظ می‌کند. یک بک‌اسلش به دنبال خط جدید ادامه سطر است و خود خط جدید دور ریخته می‌شود. یک بک‌اسلش به دنبال هر نویسه دیگری نادیده گرفته می‌شود؛ هم بک‌اسلش و هم نویسه بعدی به همان صورت حفظ می‌شوند. فاصله‌های خالی ابتدا و انتها در خارج از نقل‌قول دوتایی دور ریخته می‌شوند.

آرگومان ارسال‌شده باید یک نام فایل مطلق یا عبارت wildcard باشد، به صورت اختیاری با پیشوند "-"، که نشان می‌دهد اگر فایل وجود نداشته باشد، خوانده نخواهد شد و هیچ پیام خطا یا هشداری ثبت نمی‌شود. این گزینه ممکن است بیش از یک بار مشخص شود که در این صورت تمام فایل‌های مشخص‌شده خوانده می‌شوند. اگر رشته خالی به این گزینه اختصاص یابد، فهرست فایل‌های خواندنی بازنشانی می‌شود و تمام انتساب‌های قبلی بی‌اثر خواهند بود.

فایل‌های فهرست‌شده با این دستورالعمل کمی قبل از اجرای فرآیند خوانده می‌شوند (دقیق‌تر: پس از خاتمه تمام فرآیندهای مربوط به وضعیت قبلی واحد. این بدان معناست که می‌توانید این فایل‌ها را در یک وضعیت واحد تولید کنید و با این گزینه در وضعیت بعدی بخوانید. فایل‌ها از سیستم‌فایل مدیر سرویس، قبل از هرگونه تغییر سیستم‌فایل مانند bind mount خوانده می‌شوند).

تنظیمات حاصل از این فایل‌ها تنظیمات انجام‌شده با Environment= را بازنویسی می‌کنند. اگر یک متغیر دو بار از این فایل‌ها تنظیم شود، فایل‌ها به ترتیبی که مشخص شده‌اند خوانده می‌شوند و تنظیم بعدی تنظیم قبلی را بازنویسی خواهد کرد.

متغیرهای تنظیم‌شده برای فرآیندهای فراخوانده‌شده ناشی از این تنظیم، مشمول بازنویسی توسط موارد پیکربندی‌شده با Environment= یا EnvironmentFile= هستند.

مثال:

PassEnvironment=VAR1 VAR2 VAR3

سه متغیر "VAR1"، "VAR2"، "VAR3" را با مقادیر تنظیم‌شده برای آن متغیرها در PID1 منتقل می‌کند.

برای جزئیات درباره متغیرهای محیطی به environ(7) مراجعه کنید.

اضافه‌شده در نسخه 228.

برای توصیف نحوه ترکیب این تنظیمات برای تشکیل محیط موروثی، به "متغیرهای محیطی در فرآیندهای ایجادشده" در زیر مراجعه کنید. برای اطلاعات عمومی درباره متغیرهای محیطی به environ(7) مراجعه کنید.

اضافه‌شده در نسخه 235.

اگر null انتخاب شود، ورودی استاندارد به /dev/null متصل خواهد شد، یعنی تمام تلاش‌های خواندن توسط فرآیند منجر به EOF فوری می‌شود.

اگر tty انتخاب شود، ورودی استاندارد به یک TTY متصل می‌شود (همان‌طور که توسط TTYPath= پیکربندی شده است، به زیر مراجعه کنید) و فرآیند اجراشده به فرآیند کنترل‌کننده ترمینال تبدیل می‌شود. اگر ترمینال قبلاً توسط فرآیند دیگری کنترل شده باشد، فرآیند اجراشده تا زمانی که فرآیند کنترل‌کننده فعلی ترمینال را آزاد کند منتظر می‌ماند.

گزینه tty-force مشابه tty است، اما فرآیند اجراشده به اجبار و بلافاصله به فرآیند کنترل‌کننده ترمینال تبدیل می‌شود و احتمالاً فرآیندهای کنترل‌کننده قبلی را از ترمینال حذف می‌کند.

گزینه tty-fail مشابه tty است، اما اگر ترمینال از قبل دارای یک فرآیند کنترل‌کننده باشد، راه‌اندازی فرآیند اجراشده با شکست مواجه می‌شود.

گزینه data ممکن است برای پیکربندی داده‌های متنی یا دودویی دلخواه جهت ارسال از طریق ورودی استاندارد به فرآیند اجراشده استفاده شود. داده‌های ارسالی از طریق StandardInputText=/StandardInputData= پیکربندی می‌شوند (به زیر مراجعه کنید). توجه داشته باشید که نوع واقعی توصیف‌کننده فایل ارسالی (فایل حافظه، فایل معمولی، لوله UNIX و غیره) ممکن است به هسته و امتیازات موجود بستگی داشته باشد. در هر صورت، توصیف‌کننده فایل فقط‌خواندنی است و هنگام خواندن، داده‌های مشخص‌شده را به همراه EOF بازمی‌گرداند.

گزینه file:path ممکن است برای اتصال یک شیء سیستم‌فایل خاص به ورودی استاندارد استفاده شود. یک مسیر مطلق به دنبال نویسه ":" انتظار می‌رود که ممکن است به یک فایل معمولی، یک FIFO یا فایل ویژه اشاره داشته باشد. اگر یک سوکت AF_UNIX در سیستم‌فایل مشخص شود، یک سوکت جریانی (stream socket) به آن متصل می‌شود. مورد دوم برای اتصال ورودی استاندارد فرآیندها به سرویس‌های دلخواه سیستم مفید است.

گزینه socket فقط در سرویس‌های فعال‌شده با سوکت معتبر است و مستلزم آن است که فایل واحد سوکت مربوطه (برای جزئیات به systemd.socket(5) مراجعه کنید) دارای Accept=yes باشد، یا فقط یک سوکت منفرد را مشخص کند. اگر این گزینه تنظیم شود، ورودی استاندارد به سوکتی که سرویس از آن فعال شده است متصل خواهد شد، که این در درجه اول برای سازگاری با دیمون‌هایی مفید است که برای استفاده با دیمون فعال‌سازی سنتی سوکت inetd(8) طراحی شده‌اند (متغیرهای محیطی $LISTEN_FDS و متغیرهای مرتبط در هنگام پیکربندی مقدار socket منتقل نمی‌شوند).

گزینه fd:name ورودی استاندارد را به یک توصیف‌کننده فایل خاص و نام‌گذاری‌شده ارائه‌شده توسط یک واحد سوکت متصل می‌کند. نام ممکن است به عنوان بخشی از این گزینه، پس از نویسه ":" مشخص شود (مانند "fd:foobar"). اگر هیچ نامی مشخص نشود، نام "stdin" به صورت ضمنی در نظر گرفته می‌شود (یعنی "fd" معادل "fd:stdin" است). حداقل یک واحد سوکت که نام مشخص‌شده را تعریف می‌کند باید از طریق گزینه Sockets= ارائه شود، و نام توصیف‌کننده فایل ممکن است با نام واحد سوکت حاوی آن متفاوت باشد. اگر چندین تطابق یافت شود، از اولین مورد استفاده خواهد شد. برای جزئیات بیشتر درباره توصیف‌کننده‌های فایل نام‌گذاری‌شده و ترتیب آن‌ها به FileDescriptorName= در systemd.socket(5) مراجعه کنید.

پیش‌فرض این تنظیم روی null است، مگر اینکه StandardInputText=/StandardInputData= تنظیم شده باشند که در این صورت پیش‌فرض روی data خواهد بود.

گزینه inherit توصیف‌کننده فایل ورودی استاندارد را برای خروجی استاندارد تکثیر می‌کند.

گزینه null خروجی استاندارد را به /dev/null متصل می‌کند، یعنی هر چیزی که در آن نوشته شود از دست خواهد رفت.

گزینه tty خروجی استاندارد را به یک tty متصل می‌کند (همان‌طور که از طریق TTYPath= پیکربندی شده است، به زیر مراجعه کنید). اگر TTY فقط برای خروجی استفاده شود، فرآیند اجراشده به فرآیند کنترل‌کننده ترمینال تبدیل نخواهد شد، و متوقف نمی‌شود یا منتظر نمی‌ماند تا فرآیندهای دیگر ترمینال را آزاد کنند. نکته: اگر یک واحد سعی کند چندین خط را در حین بوت یا خاموش شدن در TTY چاپ کند، این احتمال وجود دارد که آن خطوط توسط پیام‌های وضعیت شکسته شوند. می‌توان از SetShowStatus() برای جلوگیری از این مشکل استفاده کرد. برای جزئیات به org.freedesktop.systemd1(5) مراجعه کنید.

گزینه journal خروجی استاندارد را به ژورنال (journal) متصل می‌کند که از طریق journalctl(1) قابل دسترسی است. توجه داشته باشید که هر آنچه در kmsg نوشته می‌شود (به زیر مراجعه کنید) به صورت ضمنی در ژورنال نیز ذخیره می‌شود، بنابراین گزینه خاص فهرست‌شده در زیر یک superset از این گزینه است. (همچنین توجه داشته باشید که هرگونه دیمون syslog خارجی و اضافی نیز داده‌های لاگ خود را از ژورنال دریافت می‌کند، از این رو هنگامی که ثبت وقایع باید با چنین دیمونی پردازش شود، این گزینه مورد استفاده قرار می‌گیرد.)

گزینه kmsg خروجی استاندارد را علاوه بر ژورنال، به بافر لاگ هسته که از طریق dmesg(1) قابل دسترسی است متصل می‌کند. دیمون ژورنال ممکن است به هر حال برای ارسال تمام لاگ‌ها به kmsg پیکربندی شده باشد، که در این صورت این گزینه تفاوتی با journal ندارد.

گزینه‌های journal+console و kmsg+console به روشی مشابه دو گزینه بالا عمل می‌کنند اما خروجی را در کنسول سیستم نیز کپی می‌کنند.

گزینه file:path ممکن است برای اتصال یک شیء خاص سیستم‌فایل به خروجی استاندارد استفاده شود. معنای آن مشابه همان گزینه در StandardInput= است، به بالا مراجعه کنید. اگر path به یک فایل معمولی در سیستم‌فایل اشاره کند، برای نوشتن در ابتدای فایل باز می‌شود (در صورت عدم وجود با استفاده از امتیازات کاربر اجراکننده فرآیند systemd ایجاد می‌شود)، اما بدون کوتاه کردن (truncate) آن. اگر ورودی و خروجی استاندارد به همان مسیر فایل هدایت شوند، فقط یک بار باز می‌شود — هم برای خواندن و هم برای نوشتن — و تکثیر می‌شود. این امر به‌ویژه هنگامی مفید است که مسیر مشخص‌شده به یک سوکت AF_UNIX در سیستم‌فایل اشاره داشته باشد، زیرا در آن صورت فقط یک اتصال جریانی واحد برای هر دو ورودی و خروجی ایجاد می‌شود.

گزینه append:path مشابه file:path در بالا است، اما فایل را در حالت الحاق (append mode) باز می‌کند.

گزینه truncate:path مشابه file:path در بالا است، اما فایل را هنگام باز کردن کوتاه (truncate) می‌کند. برای واحدهایی با چندین خط فرمان، به عنوان مثال سرویس‌های Type=oneshot با چندین ExecStart=، یا سرویس‌های دارای ExecCondition=، ExecStartPre= یا ExecStartPost=، فایل خروجی دوباره باز می‌شود و بنابراین برای هر خط فرمان مجدداً truncate می‌شود. اگر فایل خروجی در حالی که فرآیند دیگری هنوز فایل را باز نگه داشته است truncate شود، به عنوان مثال توسط یک ExecReload= که همزمان با یک ExecStart= اجرا می‌شود، و فرآیند دیگر بدون تنظیم افست خود به نوشتن در فایل ادامه دهد، ممکن است فضای بین اشاره‌گرهای فایل دو فرآیند با بایت‌های NUL پر شود و یک فایل پراکنده (sparse file) ایجاد کند. بنابراین، truncate:path معمولاً فقط برای واحدهایی مفید است که در آن‌ها فقط یک فرآیند در هر زمان اجرا می‌شود، مانند سرویس‌هایی با یک ExecStart= منفرد و بدون ExecStartPost=، ExecReload=، ExecStop= یا نظایر آن.

گزینه socket خروجی استاندارد را به سوکتی که از طریق فعال‌سازی سوکت به دست آمده متصل می‌کند. معنای آن مشابه همان گزینه در StandardInput= است، به بالا مراجعه کنید.

گزینه fd:name خروجی استاندارد را به یک توصیف‌کننده فایل مشخص و نام‌گذاری‌شده ارائه‌شده توسط یک واحد سوکت متصل می‌کند. یک نام ممکن است به عنوان بخشی از این گزینه، پس از نویسه ":" مشخص شود (مانند "fd:foobar"). اگر هیچ نامی مشخص نشود، نام "stdout" به صورت ضمنی در نظر گرفته می‌شود (یعنی "fd" معادل "fd:stdout" است). حداقل یک واحد سوکت که نام مشخص‌شده را تعریف می‌کند باید از طریق گزینه Sockets= ارائه شود، و نام توصیف‌کننده فایل ممکن است با نام واحد سوکت حاوی آن متفاوت باشد. اگر چندین تطابق یافت شود، از اولین مورد استفاده خواهد شد. برای جزئیات بیشتر درباره توصیف‌کننده‌های نام‌گذاری‌شده و ترتیب آن‌ها به FileDescriptorName= در systemd.socket(5) مراجعه کنید.

اگر خروجی استاندارد (یا خروجی خطا، به زیر مراجعه کنید) یک واحد به ژورنال یا بافر لاگ هسته متصل باشد، واحد به طور ضمنی وابستگی از نوع After= روی systemd-journald.socket کسب خواهد کرد (همچنین به بخش "وابستگی‌های ضمنی" در بالا مراجعه کنید). همچنین توجه داشته باشید که در این حالت stdout (یا stderr، به زیر مراجعه کنید) یک سوکت جریانی AF_UNIX خواهد بود و نه یک لوله یا FIFO که بتواند دوباره باز شود. این بدان معناست که هنگام اجرای اسکریپت‌های شل، ساختار echo "hello" > /dev/stderr برای نوشتن متن در stderr کار نخواهد کرد. برای رفع این مشکل از ساختار echo "hello" >&2 استفاده کنید که عمدتاً معادل است و از این دام جلوگیری می‌کند.

اگر StandardInput= روی یکی از موارد tty، tty-force، tty-fail، socket یا fd:name تنظیم شده باشد، پیش‌فرض این تنظیم روی inherit خواهد بود.

در سایر موارد، این تنظیم پیش‌فرض روی مقدار تعیین‌شده با DefaultStandardOutput= در systemd-system.conf(5) قرار می‌گیرد که پیش‌فرض آن journal است. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید).

این تنظیم پیش‌فرض روی مقدار تعیین‌شده با DefaultStandardError= در systemd-system.conf(5) قرار می‌گیرد که پیش‌فرض آن inherit است. توجه داشته باشید که تنظیم این پارامتر ممکن است منجر به اضافه شدن وابستگی‌های اضافی به واحد شود (به بالا مراجعه کنید).

تنظیم StandardInputText= داده‌های متنی دلخواه را می‌پذیرد. توالی‌های گریز به سبک C برای نویسه‌های خاص و همچنین تعیین‌کننده‌های معمول "%" حل‌وفصل می‌شوند. هر بار که از این تنظیم استفاده می‌شود، متن مشخص‌شده به بافر داده به ازای هر واحد اضافه می‌شود، به همراه یک نویسه خط جدید (بنابراین هر استفاده یک خط جدید را به انتهای بافر اضافه می‌کند). توجه داشته باشید که فاصله‌های خالی ابتدا و انتهای خطوط پیکربندی‌شده با این گزینه حذف می‌شوند. اگر یک خط خالی مشخص شود، بافر پاک می‌شود (بنابراین، برای درج یک خط خالی، یک "\n" اضافی به ابتدا یا انتهای یک خط اضافه کنید).

تنظیم StandardInputData= داده‌های باینری دلخواه را که با Base64[15] کدگذاری شده‌اند می‌پذیرد. هیچ توالی گریز یا تعیین‌کننده‌ای حل‌وفصل نمی‌شود. هرگونه فضای خالی در نسخه کدگذاری‌شده هنگام رمزگشایی نادیده گرفته می‌شود.

توجه داشته باشید که StandardInputText= و StandardInputData= روی یک بافر داده یکسان عمل می‌کنند و ممکن است برای پیکربندی هر دو داده باینری و متنی برای یک جریان ورودی یکسان ترکیب شوند. داده‌های متنی یا باینری دقیقاً به ترتیبی که تنظیمات در فایل واحد ظاهر می‌شوند به هم متصل می‌گردند. اختصاص یک رشته خالی به هر یک، بافر داده را بازنشانی می‌کند.

لطفاً به خاطر داشته باشید که به منظور حفظ خوانایی، تنظیمات طولانی فایل واحد ممکن است با پسوندگذاری هر خط (به جز خط آخر) با یک نویسه "\" به چندین خط تقسیم شوند (برای جزئیات به systemd.unit(5) مراجعه کنید). این امر به‌ویژه برای داده‌های بزرگ پیکربندی‌شده با این دو گزینه مفید است. مثال:

...
StandardInput=data
StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \
                  IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \
                  dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \
                  J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \
                  dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \
                  ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \
                  eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK
...

اضافه‌شده در نسخه 236.

اضافه‌شده در نسخه 236.

توجه داشته باشید که این عملکرد در حال حاضر فقط در سرویس‌های سیستمی در دسترس است، نه در سرویس‌های کاربر-محور.

اضافه‌شده در نسخه 236.

اضافه‌شده در نسخه 240.

از آنجا که نویسه "~" برای تعریف الگوهای ردشده استفاده می‌شود، باید با "\x7e" جایگزین شود تا اجازه داده شود پیامی که با "~" شروع می‌شود ثبت گردد. برای مثال، "~foobar" الگویی منطبق بر "foobar" را به فهرست مسدود اضافه می‌کند، در حالی که "\x7efoobar" الگویی منطبق بر "~foobar" را به فهرست مجاز اضافه می‌نماید.

پیام‌های لاگ ابتدا در برابر الگوهای ردشده (در صورت وجود) و سپس در برابر الگوهای مجاز (در صورت وجود) آزمایش می‌شوند. اگر یک پیام لاگ با هر یک از الگوهای ردشده مطابقت داشته باشد، بلافاصله بدون در نظر گرفتن الگوهای مجاز دور ریخته می‌شود. پیام‌های لاگ باقیمانده در برابر الگوهای مجاز آزمایش می‌شوند. پیام‌هایی که با هیچ یک از الگوهای مجاز مطابقت ندارند دور ریخته می‌شوند. اگر هیچ الگوی مجازی تعریف نشده باشد، تمام پیام‌ها مستقیماً پس از عبور از فیلترهای ردشده پردازش می‌شوند.

فیلتر کردن بر اساس واحدی است که LogFilterPatterns= برای آن تعریف شده است، به این معنی که پیام‌های لاگ دریافتی از systemd(1) درباره واحد در نظر گرفته نمی‌شوند. پیام‌های لاگ فیلترشده به دیمون‌های سنتی syslog، بافر لاگ هسته (kmsg)، کنسول systemd فوروارد نمی‌شوند و به عنوان پیام‌های سراسری (wall) برای تمام کاربران واردشده ارسال نمی‌گردند.

توجه داشته باشید که این عملکرد در حال حاضر فقط در سرویس‌های سیستمی در دسترس است، نه در سرویس‌های کاربر-محور.

اضافه‌شده در نسخه 253.

در لایه‌های درونی، فضاهای نام ژورنال از طریق فضاسازی نام اتصال لینوکس و پوشاندن دایرکتوری حاوی سوکت‌های مربوطه AF_UNIX که برای لاگ‌گیری استفاده می‌شوند در فضای نام اتصال واحد پیاده‌سازی می‌شوند. از آنجا که از فضاهای نام اتصال استفاده می‌شود، این تنظیم انتشار اتصالات از فرآیندهای واحد به میزبان را قطع می‌کند، مشابه نحوه کار ReadOnlyPaths= و تنظیمات مشابه که در بالا شرح داده شد. بنابراین فضاهای نام ژورنال ممکن است برای سرویس‌هایی که نیاز به ایجاد نقاط اتصال روی میزبان دارند استفاده نشوند.

هنگامی که از این گزینه استفاده می‌شود، واحد به طور خودکار وابستگی‌های ترتیب و نیازمندی روی دو واحد سوکت مرتبط با نمونه systemd-journald@.service کسب می‌کند تا قبل از راه‌اندازی واحد به طور خودکار ایجاد شوند. توجه داشته باشید که هنگامی که از این گزینه استفاده می‌شود، خروجی لاگ این سرویس در خروجی معمولی journalctl(1) ظاهر نمی‌شود، مگر اینکه از گزینه --namespace= استفاده شود.

این گزینه فقط برای سرویس‌های سیستمی در دسترس است و برای سرویس‌هایی که در نمونه‌های کاربر-محور مدیر سرویس اجرا می‌شوند پشتیبانی نمی‌شود.

اضافه‌شده در نسخه 245.

اضافه‌شده در نسخه 250.

تنظیم LoadCredential= یک شناسه متنی را برای استفاده به عنوان نام برای اعتبارنامه به اضافه یک مسیر سیستم‌فایل، جداشده با دونقطه می‌پذیرد. شناسه باید یک رشته کوتاه ASCII مناسب به عنوان نام فایل در سیستم‌فایل باشد، و ممکن است آزادانه توسط کاربر انتخاب شود. اگر مسیر مشخص‌شده مطلق باشد، به عنوان یک فایل معمولی باز می‌شود و داده‌های اعتبارنامه از آن خوانده می‌شود. اگر مسیر مطلق به یک سوکت جریانی AF_UNIX در سیستم‌فایل اشاره کند، اتصالی به آن برقرار می‌شود (فقط یک بار در زمان شروع واحد) و داده‌های اعتبارنامه از اتصال خوانده می‌شود، که یک نقطه یکپارچه‌سازی آسان IPC را برای انتقال پویای داده‌های اعتبارنامه از سایر سرویس‌ها فراهم می‌کند.

اگر مسیر مشخص‌شده مطلق نباشد و خود به عنوان شناسه معتبر اعتبارنامه واجد شرایط باشد، تلاش می‌شود یک اعتبارنامه که خود مدیر سرویس تحت نام مشخص‌شده دریافت کرده است پیدا شود — که ممکن است برای انتشار اعتبارنامه‌ها از یک محیط فراخواننده (مانند یک مدیر کانتینر که مدیر سرویس را فراخوانده است) به درون یک سرویس استفاده شود. اگر هیچ اعتبارنامه سیستمی منطبقی یافت نشود، دایرکتوری‌های /etc/credstore/، /run/credstore/ و /usr/lib/credstore/ برای یافتن فایل‌هایی تحت نام اعتبارنامه جستجو می‌شوند — که از این رو مکان‌های توصیه‌شده برای داده‌های اعتبارنامه روی دیسک هستند. اگر از LoadCredentialEncrypted= استفاده شود، دایرکتوری‌های /run/credstore.encrypted/، /etc/credstore.encrypted/ و /usr/lib/credstore.encrypted/ نیز جستجو می‌شوند.

اگر مسیر سیستم‌فایل حذف شود، همانند نام اعتبارنامه انتخاب می‌شود، یعنی این روشی مختصر برای اعلام اعتبارنامه‌ها برای به ارث بردن از مدیر سرویس به درون یک سرویس است. این گزینه ممکن است چندین بار استفاده شود، که هر بار یک اعتبارنامه اضافی را برای ارسال به واحد تعریف می‌کند.

توجه داشته باشید که اگر مسیر مشخص نشده باشد یا یک شناسه معتبر اعتبارنامه داده شده باشد، یعنی در دو حالت فوق، نبود یک اعتبارنامه خطای مرگبار تلقی نمی‌شود.

اگر یک مسیر مطلق اشاره‌کننده به یک دایرکتوری مشخص شود، هر فایلی در آن دایرکتوری (به صورت بازگشتی) به عنوان یک اعتبارنامه جداگانه بارگذاری خواهد شد. شناسه هر اعتبارنامه، شناسه ارائه‌شده به همراه پسوند "_$FILENAME" خواهد بود (به عنوان مثال "Key_file1"). هنگام بارگذاری از یک دایرکتوری، پیوندهای نمادین نادیده گرفته می‌شوند.

محتوای فایل/سوکت ممکن است داده‌های دودویی یا متنی دلخواه باشد، از جمله نویسه‌های خط جدید و بایت‌های NUL.

تنظیم LoadCredentialEncrypted= مشابه LoadCredential= است، به جز اینکه داده‌های اعتبارنامه قبل از ارسال به فرآیندهای اجراشده رمزگشایی و احراز اصالت می‌شوند. به طور خاص، مسیر ارجاع‌شده باید به یک فایل یا سوکت با اعتبارنامه رمزگذاری‌شده اشاره کند، همان‌طور که توسط systemd-creds(1) پیاده‌سازی شده است. این اعتبارنامه بارگذاری، رمزگشایی، احراز اصالت شده و سپس به همان روشی که یک اعتبارنامه معمولی مشخص‌شده از طریق LoadCredential= ارسال می‌شود، به شکل متن ساده به برنامه ارسال می‌گردد. اعتبارنامه‌ای که به این روش پیکربندی شده است ممکن است با یک کلید مخفی مشتق‌شده از تراشه امنیتی TPM2 سیستم، یا با یک کلید مخفی ذخیره‌شده در /var/lib/systemd/credentials.secret، یا با هر دو به صورت متقارن رمزگذاری/احراز اصالت شود. استفاده از اعتبارنامه‌های رمزگذاری‌شده و احراز اصالت‌شده امنیت را بهبود می‌بخشد زیرا اعتبارنامه‌ها به صورت متن ساده ذخیره نمی‌شوند و تنها در لحظه‌ای که سرویس نیازمند به آن‌ها شروع به کار می‌کند احراز اصالت شده و به متن ساده رمزگشایی می‌شوند. علاوه بر این، اعتبارنامه‌ها ممکن است به سخت‌افزار و نصب‌های محلی متصل شوند، به طوری که نتوان آن‌ها را به راحتی به صورت آفلاین تجزیه و تحلیل کرد یا به صورت خارجی تولید نمود. هنگامی که DevicePolicy= روی "closed" یا "strict" تنظیم شده باشد، یا روی "auto" تنظیم شده و DeviceAllow= تنظیم شده باشد، یا PrivateDevices= تنظیم شده باشد، این تنظیم /dev/tpmrm0 را با حالت rw به DeviceAllow= اضافه می‌کند. برای جزئیات درباره DevicePolicy= یا DeviceAllow= به systemd.resource-control(5) مراجعه کنید.

توجه داشته باشید که اعتبارنامه‌های رمزگذاری‌شده که برای سرویس‌های مدیر سرویس کاربر-محور در نظر گرفته شده‌اند باید با systemd-creds encrypt --user رمزگذاری شوند، و موارد مربوط به مدیر سرویس سیستم بدون سوئیچ --user رمزگذاری شوند. اعتبارنامه‌های رمزگذاری‌شده همیشه یک کاربر خاص یا کل سیستم را هدف قرار می‌دهند، و این اطمینان حاصل می‌شود که مدیران سرویس کاربر نمی‌توانند اسرار در نظر گرفته‌شده برای سیستم یا سایر کاربران را رمزگشایی کنند.

فایل‌های اعتبارنامه/سوکت‌های IPC باید برای مدیر سرویس قابل دسترسی باشند، اما لازم نیست مستقیماً برای فرآیندهای واحد قابل دسترسی باشند: داده‌های اعتبارنامه خوانده شده و در نسخه‌های جداگانه و فقط‌خواندنی برای واحد کپی می‌شوند که برای فرآیندهای با امتیاز مناسب قابل دسترسی هستند. این امر به‌ویژه در ترکیب با DynamicUser= مفید است، زیرا از این طریق می‌توان داده‌های دارای امتیاز را در دسترس فرآیندهایی قرار داد که تحت یک UID پویا (یعنی نه یک UID شناخته‌شده از قبل) اجرا می‌شوند، بدون اینکه نیازی به باز کردن دسترسی برای همه کاربران باشد.

به منظور ارجاع به مسیری که یک اعتبارنامه ممکن است از داخل یک خط فرمان ExecStart= خوانده شود، از "${CREDENTIALS_DIRECTORY}/mycred" استفاده کنید، مانند "ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred". به منظور ارجاع به مسیری که یک اعتبارنامه ممکن است از داخل یک خط Environment= خوانده شود، از "%d/mycred" استفاده کنید، مانند "Environment=MYCREDPATH=%d/mycred". برای سرویس‌های سیستمی در مواردی که هیچ جایگذاری امکان‌پذیر نیست (مثلاً فایل‌های پیکربندی نرم‌افزاری که هنوز به صورت بومی از اعتبارنامه‌ها پشتیبانی نمی‌کند)، مسیر ممکن است به عنوان "/run/credentials/UNITNAME" نیز ارجاع داده شود. با این حال، $CREDENTIALS_DIRECTORY رابط اصلی برای جستجوی اعتبارنامه‌ها در نظر گرفته می‌شود، زیرا برای سرویس‌های کاربری نیز کار می‌کند.

در حال حاضر، محدودیت اندازه کل انباشته اعتبارنامه به میزان 1 مگابایت به ازای هر واحد اعمال می‌شود.

خود مدیر سرویس ممکن است اعتبارنامه‌های سیستمی را دریافت کند که می‌توانند از یک مدیر کانتینر میزبان یا هایپروایزر ماشین مجازی به سرویس‌ها منتشر شوند. برای جزئیات در مورد مورد اول، مستندات Container Interface[16] را ببینید. برای مورد دوم، ورودی‌های جدول رشته OEM در DMI/SMBIOS[17] (نوع فیلد 11) را با پیشوند "io.systemd.credential:" یا "io.systemd.credential.binary:" ارسال کنید. در هر دو حالت یک جفت کلید/مقدار جداشده با "=" انتظار می‌رود؛ در حالت دوم سمت راست هنگام تجزیه Base64 رمزگشایی می‌شود (بنابراین اجازه می‌دهد داده‌های دودویی ارسال شوند). سوئیچ مثال qemu[18]: "-smbios type=11,value=io.systemd.credential:xx=yy"، یا "-smbios type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=". به عنوان روش جایگزین، از گره "fw_cfg" در qemu به صورت "opt/io.systemd.credentials/" استفاده کنید. سوئیچ مثال qemu: "-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret". آن‌ها همچنین ممکن است از محیط سفت‌افزار UEFI از طریق systemd-stub(7)، از initrd (به systemd(1) مراجعه کنید)، یا در خط فرمان هسته با استفاده از سوئیچ‌های "systemd.set_credential=" و "systemd.set_credential_binary=" مشخص شوند (به systemd(1) مراجعه کنید — این مورد توصیه نمی‌شود زیرا فضای کاربری بدون امتیاز می‌تواند خط فرمان هسته را بخواند).

در صورت ارجاع به یک سوکت جریانی AF_UNIX برای اتصال، اتصال از یک سوکت فضای نام انتزاعی سرچشمه می‌گیرد که شامل اطلاعاتی درباره واحد و شناسه اعتبارنامه در نام سوکت خود است. از getpeername(2) برای پرس‌وجوی این اطلاعات استفاده کنید. نام سوکت بازگردانده‌شده به صورت NUL RANDOM "/unit/" UNIT "/" ID قالب‌بندی می‌شود، یعنی یک بایت NUL (همان‌طور که برای نام‌های سوکت فضای نام انتزاعی لازم است)، به دنبال آن یک رشته تصادفی (شامل نویسه‌های الفبایی-عددی)، به دنبال آن رشته لغوی "/unit/"، به دنبال آن نام واحد درخواست‌کننده، به دنبال آن نویسه لغوی "/"، به دنبال آن شناسه متنی اعتبارنامه درخواستی. مثال: "\0adf9d86b6eda275e/unit/foobar.service/credx" در صورتی که اعتبارنامه "credx" برای یک واحد "foobar.service" درخواست شده باشد. این عملکرد برای استفاده از یک سوکت شنیداری منفرد برای ارائه اعتبارنامه‌ها به چندین مصرف‌کننده مفید است.

برای اطلاعات بیشتر، مستندات System and Service Credentials[19] را ببینید.

اضافه‌شده در نسخه 247.

عبارت globbing زیرمجموعه محدودی از glob(7) را پیاده‌سازی می‌کند: فقط یک نویسه عام پایانی "*" ممکن است مشخص شود. هر دو نویسه عام "?" و "[]" مجاز نیستند، و نویسه عام "*" نیز در هیچ جایی به جز انتهای عبارت glob مجاز نیست.

به صورت اختیاری، نام یا الگوی اعتبارنامه ممکن است با یک دونقطه و سپس یک الگوی تغییر نام همراه باشد. در صورت مشخص شدن، تمام اعتبارنامه‌های منطبق بر نام اعتبارنامه یا glob طبق الگوی ارائه‌شده تغییر نام می‌یابند. برای مثال، اگر "ImportCredential=my.original.cred:my.renamed.cred" مشخص شود، مدیر سرویس اعتبارنامه "my.original.cred" را خوانده و آن را به عنوان اعتبارنامه "my.renamed.cred" در دسترس سرویس قرار می‌دهد. مشابهاً، اگر "ImportCredential=my.original.*:my.renamed." مشخص شود، مدیر سرویس تمام اعتبارنامه‌هایی را که با "my.original." شروع می‌شوند خوانده و آن‌ها را به عنوان "my.renamed.xxx" در دسترس سرویس قرار می‌دهد.

اگر ImportCredential= چندین بار مشخص شود و چندین اعتبارنامه پس از تغییر نام با نام یکسانی خاتمه یابند، اولین مورد حفظ شده و موارد بعدی حذف می‌شوند.

هنگامی که چندین اعتبارنامه با همان نام یافت شوند، اعتبارنامه‌های یافت‌شده توسط LoadCredential= و LoadCredentialEncrypted= بر اعتبارنامه‌های یافت‌شده توسط ImportCredential= اولویت دارند.

اضافه‌شده در نسخه 254.

تنظیم SetCredentialEncrypted= مشابه SetCredential= است اما یک اعتبارنامه رمزگذاری‌شده را به شکل لغوی به عنوان مقدار انتظار دارد. این امر اجازه می‌دهد اعتبارنامه‌های محرمانه مستقیماً در فایل‌های واحد به صورت ایمن تعبیه شوند. از سوئیچ -p در systemd-creds(1) برای تولید مستقیم خطوط مناسب SetCredentialEncrypted= از اعتبارنامه‌های متن ساده استفاده کنید. برای جزئیات بیشتر به LoadCredentialEncrypted= در بالا مراجعه کنید.

هنگامی که چندین اعتبارنامه با همان نام یافت شوند، اعتبارنامه‌های یافت‌شده توسط LoadCredential=، LoadCredentialEncrypted= و ImportCredential= بر اعتبارنامه‌های یافت‌شده توسط SetCredential= اولویت دارند. به این ترتیب، اگر هیچ اعتبارنامه‌ای توسط هیچ یک از موارد قبلی یافت نشود، SetCredential= به عنوان پیش‌فرض عمل خواهد کرد. در این حالت، عدم امکان بازیابی اعتبارنامه از مسیر مشخص‌شده در LoadCredential= یا LoadCredentialEncrypted= خطای مرگبار تلقی نمی‌شود.

اضافه‌شده در نسخه 247.

اضافه‌شده در نسخه 225.

[Unit]
Description=Service which can trigger an OnFailure= dependency
OnFailure=myhandler.service
[Service]
ExecStart=/bin/myprogram

[Unit]
Description=Service which can trigger an OnSuccess= dependency
OnSuccess=myhandler.service
[Service]
ExecStart=/bin/mysecondprogram

[Unit]
Description=Acts on service failing or succeeding
[Service]
ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT"

MONITOR_SERVICE_RESULT=exit-code
MONITOR_EXIT_CODE=exited
MONITOR_EXIT_STATUS=1
MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236
MONITOR_UNIT=myfailer.service

MONITOR_SERVICE_RESULT=success
MONITOR_EXIT_CODE=exited
MONITOR_EXIT_STATUS=0
MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697
MONITOR_UNIT=mysuccess.service