أُضيف في الإصدار 250.

يُعد الإعدادان MountAPIVFS= و PrivateUsers= مفيدين بشكل خاص بالاقتران مع RootDirectory=. للتفاصيل، انظر أدناه.

إذا استُخدم RootDirectory=/RootImage= مع NotifyAccess=، فيُوصل مقبس الإشعار آليًا من المضيف إلى بيئة الجذر، لضمان عمل واجهة الإشعارات بشكل صحيح.

لاحظ أن الخدمات التي تستخدم RootDirectory=/RootImage= لن تتمكن من التسجيل عبر بروتوكولات syslog أو journal في البنية التحتية لتسجيل المضيف، ما لم تُوصل المقابس المعنية من المضيف، وتحديدًا:

سيُتاح ملف os-release(5) الخاص بالمضيف للخدمة (للقراءة فقط) كـ /run/host/os-release. وسيُحدّث آليًا عند إعادة التشغيل المرنة (انظر: 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=. انظر systemd.resource-control(5) للتفاصيل حول DevicePolicy= أو DeviceAllow=. وأيضًا، انظر PrivateDevices= أدناه، لأنه قد يغير إعداد DevicePolicy=.

الوحدات التي تستخدم RootImage= تكتسب آليًا اعتمادية After= على systemd-udevd.service.

سيُتاح ملف os-release(5) الخاص بالمضيف للخدمة (للقراءة فقط) كـ /run/host/os-release. وسيُحدّث آليًا عند إعادة التشغيل المرنة (انظر: systemd-soft-reboot.service(8))، في حال هُيئت الخدمة للبقاء بعدها.

بدلاً من مسار الصورة، يمكن تحديد دليل بنسخة ".v/"، راجع systemd.v(7) للمزيد من التفاصيل.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

أُضيف في الإصدار 233.

تتبع أسماء الأقسام الصالحة مواصفة Discoverable Partitions Specification[1]: root, usr, home, srv, esp, xbootldr, tmp, var.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن استخدام خيارات الوصل يكون معطلاً مبدئيًا، نظرًا للآثار الأمنية. يمكن استخدام سياسة polkit[2] للسماح بخيارات وصل معينة، على سبيل المثال:

مثال 3. سياسة polkit تسمح بوصل قسم الجذر باستخدام nosuid ‏/etc/polkit-1/rules.d/mountoptions.rules:

polkit.addRule(function(action, subject) {


    if (action.id == "io.systemd.mount-file-system.mount-untrusted-image-privately" &&


            action.lookup("mount_options") == "root:nosuid") {


        return polkit.Result.YES;


    }
});

أُضيف في الإصدار 247.

للتأكد من إمكانية إنشاء نسخ زائلة بكفاءة، يجب أن يقع دليل الجذر أو صورة الجذر على نفس نظام الملفات الذي يقع عليه /var/lib/systemd/ephemeral-trees/. عند استخدام RootEphemeral= مع أدلة الجذر، ينبغي استخدام btrfs(5) كنظام ملفات، ويُفضل أن يكون دليل الجذر حجمًا فرعيًا يمكن لـ systemd أخذ لقطة له لإنشاء النسخة الزائلة. بالنسبة لصور الجذر، ينبغي استخدام نظام ملفات يدعم الروابط المرجعية (reflinks) لضمان نسخة زائلة كفؤة.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

أُضيف في الإصدار 254.

إذا كانت صورة القرص تحتوي على قسم /usr/ منفصل، فقد يكون محميًا أيضًا بواسطة Verity، وفي هذه الحالة يمكن تهيئة مفروم الجذر عبر سمة موسعة "user.verity.usrhash" أو ملف .usrhash مجاور لصورة القرص. لا يوجد حاليًا خيار لتهيئة مفروم الجذر لنظام ملفات /usr/ عبر ملف الوحدة مباشرة.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

أُضيف في الإصدار 246.

إذا كانت صورة القرص تحتوي على قسم /usr/ منفصل، فقد يكون محميًا أيضًا بواسطة Verity، وفي هذه الحالة يمكن تهيئة توقيع مفروم الجذر عبر ملف .usrhash.p7s مجاور لصورة القرص. لا يوجد حاليًا خيار لتهيئة توقيع مفروم الجذر لـ /usr/ عبر ملف الوحدة مباشرة.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

أُضيف في الإصدار 246.

هذا الخيار مدعوم فقط لصور الأقراص التي تحتوي على نظام ملفات واحد، بدون جدول أقسام مغلف. الصور التي تحتوي على جدول أقسام GPT يجب بدلاً من ذلك أن تتضمن كلاً من نظام ملفات الجذر وبيانات Verity المطابقة في نفس الصورة، لتنفيذ Discoverable Partitions Specification[1].

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

أُضيف في الإصدار 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.

نظرًا لأن أدلة .mstack/ قد تشير إلى صور أقراص (DDIs)، فإن ملحقات سياسة الجهاز والاعتماديات المماثلة تكون سارية المفعول عند استخدام RootMStack= كما هو الحال عند استخدام RootImage=.

بدلاً من مسار الصورة، يمكن تحديد دليل بنسخة ".v/"، راجع systemd.v(7) للمزيد من التفاصيل.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

أُضيف في الإصدار 260.

من أجل السماح بنشر عمليات الوصل في وقت التشغيل بطريقة آمنة، سيُستخدم ‎/run/systemd/propagate/‎ على المضيف لإعداد عمليات وصل جديدة، وسيُستخدم ‎/run/host/incoming/‎ في مساحة الاسم الخاصة كخطوة وسيطة لتخزينها قبل نقلها إلى نقطة الوصل النهائية.

أُضيف في الإصدار 233.

هذا الخيار مفهوم ضمنيًا عند استخدام LogNamespace=، أو عندما يكون MountAPIVFS=yes، أو عند استخدام PrivateDevices=yes بالاقتران مع RootDirectory= أو RootImage=.

أُضيف في الإصدار 257.

إذا كانت النواة لا تدعم خيارات الوصل hidepid= لكل نقطة وصل، فإن هذا الإعداد يظل بدون تأثير، وستكون عمليات الوحدة قادرة على الوصول إلى العمليات الأخرى ورؤيتها كما لو لم يُستخدم الخيار.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

أُضيف في الإصدار 247.

تمامًا مثل ProtectProc= أعلاه، يُنفّذ هذا عبر مساحات أسماء وصل نظام الملفات، وبالتالي تنطبق نفس القيود: فهو متاح فقط لخدمات النظام، ويعطل نشر الوصل إلى جدول وصل المضيف، ويتضمن ضمنيًا MountAPIVFS=. أيضًا، مثل ProtectProc=، يُعطل هذا الإعداد بلطف إذا كانت النواة المستخدمة لا تدعم خيار الوصل "subset=" لـ "procfs".

أُضيف في الإصدار 247.

ينشئ BindPaths= عمليات وصل ملزمة عادية قابلة للكتابة (ما لم يكن وصل نظام ملفات المصدر معينًا بالفعل كقراءة فقط)، بينما ينشئ BindReadOnlyPaths= عمليات وصل ملزمة للقراءة فقط. يمكن استخدام هذه الإعدادات أكثر من مرة، كل استخدام يلحق بقائمة الوحدة لعمليات الوصل الملزمة. إذا عُيّنت سلسلة نصية فارغة لأي من هذين الخيارين، فستُصفّر قائمة عمليات الوصل الملزمة بالكامل والمحددة قبل ذلك. لاحظ أنه في هذه الحالة، تُصفّر كل من عمليات الوصل الملزمة للقراءة فقط والعادية، بغض النظر عن الإعدادين المستخدمين.

يقتضي استخدام هذا الخيار تخصيص مساحة اسم وصل للوحدة، أي أنه يقتضي تأثير PrivateMounts= (انظر أدناه).

هذا الخيار مفيد بشكل خاص عند استخدام RootDirectory=/RootImage=. في هذه الحالة، يشير مسار المصدر إلى مسار على نظام ملفات المضيف، بينما يشير مسار الوجهة إلى مسار أسفل دليل الجذر للوحدة.

لاحظ أن دليل الوجهة يجب أن يكون موجودًا أو يجب أن يكون systemd قادرًا على إنشائه. وبالتالي، لا يمكن استخدام هذه الخيارات لنقاط الوصل المتداخلة أسفل المسارات المحددة في InaccessiblePaths=، أو أسفل /home/ والأدلة المحمية الأخرى إذا حُدد ProtectHome=yes. وينبغي استخدام TemporaryFileSystem= مع ":ro" أو ProtectHome=tmpfs بدلاً من ذلك.

أُضيف في الإصدار 233.

يمكن تعريف خيارات الوصل كقائمة واحدة مفصولة بفاصلة من الخيارات، وفي هذه الحالة ستُطبق ضمنيًا على قسم الجذر في الصورة، أو سلسلة من الصفوف المفصولة بنقطتين رأسيتين لاسم القسم وخيارات الوصل. أسماء الأقسام وخيارات الوصل الصالحة هي نفسها الخاصة بإعداد RootImageOptions= الموصوف أعلاه.

قد يُسبق كل تعريف وصل بـ "-"، وفي هذه الحالة سيُتجاهل عندما يكون مسار مصدره غير موجود. المعامل المصدر هو مسار لعقدة جهاز كتلي أو ملف عادي. إذا كان المصدر أو الوجهة يحتويان على ":"، فيجب هروبه كـ "\:". يجب أن تتبع عقدة الجهاز أو ملف صورة نظام الملفات نفس القواعد المحددة لـ RootImage=. أي عمليات وصل تُنشأ بهذا الخيار تكون خاصة بالوحدة، وغير مرئية في جدول وصل المضيف.

يمكن استخدام هذه الإعدادات أكثر من مرة، كل استخدام يلحق بقائمة الوحدة لمسارات الوصل. إذا عُيّنت سلسلة نصية فارغة، فستُصفّر قائمة مسارات الوصل بالكامل والمحددة قبل ذلك.

لاحظ أن دليل الوجهة يجب أن يكون موجودًا أو يجب أن يكون systemd قادرًا على إنشائه. وبالتالي، لا يمكن استخدام هذه الخيارات لنقاط الوصل المتداخلة أسفل المسارات المحددة في InaccessiblePaths=، أو أسفل /home/ والأدلة المحمية الأخرى إذا حُدد ProtectHome=yes.

عندما يُعين DevicePolicy= إلى "closed" أو "strict"، أو يُعين إلى "auto" ويُحدد DeviceAllow=، يضيف هذا الإعداد /dev/loop-control بالوضع rw، و "block-loop" و "block-blkext" بالوضع rwm إلى DeviceAllow=. انظر systemd.resource-control(5) للتفاصيل حول DevicePolicy= أو DeviceAllow=. وأيضًا، انظر PrivateDevices= أدناه، لأنه قد يغير إعداد DevicePolicy=.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن استخدام خيارات الوصل يكون معطلاً مبدئيًا، نظرًا للآثار الأمنية. يمكن استخدام سياسة polkit[2] للسماح بخيارات وصل معينة، على سبيل المثال:

مثال 5. سياسة polkit تسمح بوصل قسم الجذر باستخدام nosuid ‏/etc/polkit-1/rules.d/mountoptions.rules:

polkit.addRule(function(action, subject) {


    if (action.id == "io.systemd.mount-file-system.mount-untrusted-image-privately" &&


            action.lookup("mount_options") == "root:nosuid") {


        return polkit.Result.YES;


    }
});

أُضيف في الإصدار 247.

سيُعد OverlayFS للقراءة فقط فوق هرميات /usr/ و /opt/ لصور sysext وهرمية /etc/ لصور confext. سيحدد الترتيب الذي تُدرج به الصور الترتيب الذي يوضع به التراكب: ستؤدي الصور المحددة من الأولى إلى الأخيرة إلى طبقات 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.

إذا استخدمت خدمة ما هذا الخيار مع systemd.v(7)، وكان خيار RefreshOnReload=extensions مفعلاً (وهو المبدئي)، فستُنعش امتدادات confext لالتقاط أي تغييرات عند إعادة تحميل الخدمة. ينطبق هذا فقط على امتدادات confext. لاحظ أنه في حال كانت الخدمة تملك هذا الإعداد مفعلاً في البداية، ثم أُزيل لاحقًا في تحديث متبوع بعملية daemon-reload، فإن إعادة تحميل امتدادات confext لن تؤدي أي وظيفة (no-op)، ويلزم إعادة تشغيل الخدمة بالكامل بدلاً من ذلك. انظر systemd.service(5) أيضًا للتفاصيل.

عندما يُعين DevicePolicy= إلى "closed" أو "strict"، أو يُعين إلى "auto" ويُحدد DeviceAllow=، يضيف هذا الإعداد /dev/loop-control بالوضع rw، و "block-loop" و "block-blkext" بالوضع rwm إلى DeviceAllow=. انظر systemd.resource-control(5) للتفاصيل حول DevicePolicy= أو DeviceAllow=. وأيضًا، انظر PrivateDevices= أدناه، لأنه قد يغير إعداد DevicePolicy=.

بدلاً من مسار الصورة، يمكن تحديد دليل بنسخة ".v/"، راجع systemd.v(7) للمزيد من التفاصيل.

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن هذا الخيار يُمكّن ضمنيًا PrivateUsers= (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=") ويعتمد أيضًا على systemd-mountfsd.service(8).

عند تمكينه للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة، فإن استخدام خيارات الوصل يكون معطلاً مبدئيًا، نظرًا للآثار الأمنية. يمكن استخدام سياسة polkit[2] للسماح بخيارات وصل معينة، على سبيل المثال:

مثال 7. سياسة polkit تسمح بوصل قسم الجذر مع nosuid /etc/polkit-1/rules.d/mountoptions.rules:

polkit.addRule(function(action, subject) {


    if (action.id == "io.systemd.mount-file-system.mount-untrusted-image-privately" &&


            action.lookup("mount_options") == "root:nosuid") {


        return polkit.Result.YES;


    }
});

أُضيف في الإصدار 248.

سيعَد نظام ملفات تراكبي (OverlayFS) للقراءة فقط فوق هرميات /usr/ و /opt/ لصور sysext وهرمية /etc/ لصور confext. يحدد الترتيب الذي تُسرد به الأدلة الترتيب الذي توضع به الطبقات التراكبية: الأدلة المحددة من الأول إلى الآخر سينتج عنها طبقات overlayfs من الأسفل إلى الأعلى.

كل دليل مسرود في ExtensionDirectories= يمكن أن يسبق بعلامة "-"، وفي هذه الحالة سيُتجاهل عندما لا يكون مساره المصدري موجودًا. أي عمليات وصل تُنشأ بهذا الخيار تكون مقتصرة على الوحدة، ولا تظهر في جدول الوصل الخاص بالمضيف.

يمكن استخدام هذه الإعدادات أكثر من مرة، حيث يضيف كل استخدام إلى قائمة مسارات أدلة الوحدة. إذا عُينت سلسلة نصية فارغة، فستُصفّر قائمة مسارات الوصل بأكملها والمعرفة قبل هذا الإجراء.

يجب أن يحتوي كل دليل sysext على ملف /usr/lib/extension-release.d/extension-release.IMAGE بينما يجب أن يحمل كل دليل confext ملف /etc/extension-release.d/extension-release.IMAGE، مع البيانات الميتا المناسبة التي تطابق RootImage=/RootDirectory= أو المضيف. انظر: os-release(5).

إذا استخدمت خدمة ما هذا الخيار مع systemd.v(7)، وكان خيار RefreshOnReload=extensions مفعلاً (وهو المبدئي)، فستُنعش امتدادات confext لالتقاط أي تغييرات عند إعادة تحميل الخدمة. ينطبق هذا فقط على امتدادات confext. لاحظ أنه في حال كانت الخدمة تملك هذا الإعداد مفعلاً في البداية، ثم أُزيل لاحقًا في تحديث متبوع بعملية daemon-reload، فإن إعادة تحميل امتدادات confext لن تؤدي أي وظيفة (no-op)، ويلزم إعادة تشغيل الخدمة بالكامل بدلاً من ذلك. انظر systemd.service(5) أيضًا للتفاصيل.

لاحظ أن الاستخدام من وحدات المستخدم يتطلب دعم overlayfs في مساحات أسماء المستخدمين غير الممتدة الصلاحيات، وهو ما قُدّم لأول مرة في النواة v5.11.

بدلاً من مسار الدليل، يُمكن تحديد دليل ذي إصدار ".v/"، راجع systemd.v(7) للتفاصيل.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن PrivateUsers= ضمنيًا (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=").

أُضيف في الإصدار 251.

لاحظ أن هذا يفرض قيودًا ضعيفة فقط على صيغة اسم المستخدم/المجموعة، ولكنه سيولد تحذيرات في العديد من الحالات التي لا تلتزم فيها أسماء المستخدمين/المجموعات بالقواعد التالية: يجب أن يتكون الاسم المحدد فقط من الحروف a-z، A-Z، 0-9، "_" و "-"، باستثناء الحرف الأول الذي يجب أن يكون أحد الحروف a-z أو A-Z أو "_" (أي أن الأرقام وعلامة "-" غير مسموح بها كحرف أول). يجب أن يحتوي اسم المستخدم/المجموعة على حرف واحد على الأقل، و31 حرفًا على الأكثر. وُضعت هذه القيود لتجنب اللبس ولضمان بقاء أسماء المستخدمين/المجموعات وملفات الوحدات قابلة للنقل بين أنظمة Linux. لمزيد من التفاصيل حول الأسماء المقبولة والأسماء التي يُحذر منها، انظر صيغة اسم المستخدم/المجموعة[4].

عند استخدامه بالاقتران مع DynamicUser=، يُخصّص اسم المستخدم/المجموعة المحدد آليًا وديناميكيًا في الوقت الذي تبدأ فيه الخدمة، ويُحرّر في الوقت الذي تتوقف فيه الخدمة — ما لم يكن مخصصًا بشكل ساكن بالفعل (انظر أدناه). إذا لم يُستخدم DynamicUser=، فيجب أن يكون المستخدم والمجموعة المحددان قد أُنشئا بشكل ساكن في قاعدة بيانات المستخدمين في موعد لا يتجاوز لحظة بدء الخدمة، على سبيل المثال باستخدام أداة sysusers.d(5)، والتي تُطبّق عند الإقلاع أو وقت تثبيت الحزمة. إذا لم يكن المستخدم موجودًا بحلول ذلك الوقت، فستفشل عملية استدعاء البرنامج.

إذا أُعمل إعداد User=، فتُهيّأ قائمة المجموعات الإضافية من قائمة المجموعات المبدئية للمستخدم المحدد، كما هي معرفة في قاعدة بيانات المستخدمين والمجموعات الخاصة بالنظام. يمكن ضبط مجموعات إضافية من خلال إعداد SupplementaryGroups= (انظر أدناه).

أُضيف في الإصدار 232.

أُضيف في الإصدار 255.

لاحظ أنه لكل وحدة تستخدم هذا الخيار، ستُصان عملية معالج جلسة PAM كجزء من الوحدة وتظل موجودة طالما أن الوحدة نشطة، لضمان إمكانية اتخاذ الإجراءات المناسبة عند إنهاء الوحدة وبالتالي إنهاء جلسة PAM. تُسمى هذه العملية "(sd-pam)" وهي عملية ابن مباشرة للعملية الرئيسة للوحدة.

لاحظ أنه عند استخدام هذا الخيار لوحدة ما، فمن المحتمل جدًا (اعتمادًا على تهيئة PAM) أن تُنقل عملية الوحدة الرئيسة إلى وحدة نطاق الجلسة الخاصة بها عند تنشيطها. وبالتالي ستكون هذه العملية مرتبطة بوحدتين: الوحدة التي بُدئت منها في الأصل (والتي هُيئ لها PAMName=)، ووحدة نطاق الجلسة. ومع ذلك، فإن أي عمليات ابن لتلك العملية ستكون مرتبطة بوحدة نطاق الجلسة فقط. لهذا عواقب عند الاستخدام بالاقتران مع NotifyAccess=all، حيث لن تتمكن هذه العمليات الابن من التأثير على التغييرات في الوحدة الأصلية من خلال رسائل الإشعارات. ستُعتبر هذه الرسائل تابعة لوحدة نطاق الجلسة وليس للوحدة الأصلية. لذلك لا يُوصى باستخدام PAMName= بالاقتران مع NotifyAccess=all.

إذا طلبت وحدة PAM مدخلات بشكل تفاعلي (كلمة مرور أو ما شابه)، فستُحاول قراءتها من بيانات استيثاق الخدمة (كما هي مهيأة عبر SetCredential= و ImportCredential= والاستدعاءات ذات الصلة) تحت الاسم pam.authtok. pamservice، حيث يُستبدل pamservice باسم خدمة PAM المهيأ باستخدام PAMName=. (لاحظ أن بيانات الاستيثاق تظل سهلة الوصول لطوال وقت تشغيل الخدمة!) إذا لم تُضبط بيانات استيثاق مطابقة، فسيُطلب من المستخدم إدخالها تفاعليًا عبر منطق عميل كلمة المرور[5].

استخدم أمر 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.

لاحظ أن معظم حدود موارد العملية المهيأة بهذه الخيارات تكون لكل عملية (per-process)، ويمكن للعمليات أن تتفرع (fork) للحصول على مجموعة جديدة من الموارد التي تُحتسب بشكل مستقل عن العملية الأصلية، وبالتالي قد تفلت من الحدود المضبوطة. لاحظ أيضًا أن LimitRSS= غير مدعوم في Linux، وضبطه ليس له أي تأثير. يُنصح غالبًا بتفضيل عناصر التحكم في الموارد المسرودة في systemd.resource-control(5) على هذه الحدود التي تكون لكل عملية، لأنها تنطبق على الخدمات ككل، ويمكن تعديلها ديناميكيًا في وقت التشغيل، وهي أكثر تعبيرًا بشكل عام. على سبيل المثال، يُعد MemoryMax= بديلًا أكثر قوة (ويعمل فعليًا) لـ LimitRSS=.

لاحظ أن LimitNPROC= سيحدد عدد العمليات التابعة لمعرّف مستخدم (حقيقي) واحد (UID) وليس عدد العمليات التي بدأتها (أو فرعتها) الخدمة. لذلك فإن الحد تراكمي لجميع العمليات التي تعمل تحت نفس الـ UID. يُرجى أيضًا ملاحظة أن LimitNPROC= لن يُفرض إذا كانت الخدمة تعمل كجزء من حساب root (ولم تتخلَ عن الامتيازات). نظرًا لهذه القيود، فإن خيار TasksMax= (انظر systemd.resource-control(5)) هو عادة خيار أفضل من LimitNPROC=.

تؤول حدود الموارد غير المهيأة صراحةً لوحدة ما مبدئيًا إلى القيمة المهيأة في الخيارات المتنوعة لـ DefaultLimitCPU= و DefaultLimitFSIZE= و ... المتاحة في systemd-system.conf(5)، و—إذا لم تُهيأ هناك—تؤول إلى القيم المبدئية للنواة أو لكل مستخدم، كما هو معرف من قِبل نظام التشغيل (الأخير فقط لخدمات المستخدم، انظر أدناه).

بالنسبة لوحدات النظام، يمكن اختيار حدود الموارد هذه بحرية. عند تهيئة هذه الإعدادات في خدمة مستخدم (أي خدمة تُشغل بواسطة حالة مدير الخدمات الخاصة بكل مستخدم) لا يمكن استخدامها لرفع الحدود أعلى من تلك المضبوطة لمدير المستخدم نفسه عند استدعائه لأول مرة، حيث يفتقر مدير خدمات المستخدم عمومًا إلى الامتيازات اللازمة للقيام بذلك. في سياق المستخدم، تكون خيارات التهيئة هذه مفيدة فقط لخفض الحدود الممررة أو لرفع الحد المرن إلى الحد الأقصى للحد الصارم كما هو مهيأ للمستخدم. لرفع حدود المستخدم بشكل أكبر، تختلف آليات التهيئة المتاحة بين أنظمة التشغيل، ولكنها تتطلب عادةً امتيازات. في معظم الحالات، يمكن تهيئة حدود موارد أعلى لكل مستخدم عبر PAM أو عن طريق ضبط الحدود على خدمة النظام التي تغلف مدير خدمات المستخدم، أي حالة المستعمل من user@.service. بعد إجراء هذه التغييرات، تأكد من إعادة تشغيل مدير خدمات المستخدم.

جدول 1. توجيهات حد الموارد، وما يعادلها من أوامر صدفة ulimit والوحدة المستخدمة

مثال 8. إضافة صفحات 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[9]، فستكون الدلائل المحددة مملوكة للمستخدم "nobody" في نطاق أسماء المضيف وستُربط بـ (وستكون مملوكة لـ) معرف المستخدم/المجموعة (UID/GID) الخاص بالخدمة في نطاق أسمائها الخاص. للتوافق مع الإصدارات السابقة، سيُحتفظ بالدلائل الحالية المنشأة بدون وصولات id-mapped دون مساس.

جدول 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 على التوالي، وهي دلائل مضيف تُجعل غير قابلة للوصول للمستخدمين غير ذوي الامتيازات، مما يضمن عدم إمكانية الوصول إلى هذه الدلائل من خلال إعادة تدوير معرف المستخدم الديناميكي. تُنشأ روابط رمزية لإخفاء هذا الاختلاف في السلوك. وبالتالي، تظهر الدلائل ذات الصلة دائمًا مباشرة أسفل /var/cache و /var/log و /var/lib، سواء من منظور المضيف أو من داخل الوحدة.

استخدم RuntimeDirectory= لإدارة دليل تشغيل واحد أو أكثر للوحدة وربط عمرها بعمر تشغيل العفريت (daemon). هذا مفيد بشكل خاص للعفاريت غير ذات الامتيازات التي لا يمكنها إنشاء دلائل تشغيل في /run/ بسبب الافتقار إلى الامتيازات، وللتأكد من تنظيف دليل التشغيل آليًا بعد الاستخدام. بالنسبة لدلائل التشغيل التي تتطلب تكوينًا أكثر تعقيدًا أو اختلافًا أو ضمانات لعمرها، يرجى التفكير في استخدام tmpfiles.d(5).

تدعم خيارات RuntimeDirectory= و StateDirectory= و CacheDirectory= و LogsDirectory= اختياريًا معامِلين إضافيين، يفصل بينهما ":". سيُفسر المعامل الثاني كمسار وجهة سيُنشأ كرابط رمزي للدليل. ستُنشأ الروابط الرمزية بعد إعداد أي خيارات BindPaths= أو TemporaryFileSystem=، لإتاحة إمكانية الربط الرمزي سريع الزوال. يمكن للمصدر نفسه أن يمتلك روابط رمزية متعددة، باستخدام المعامل الأول نفسه، ولكن بمعامل ثاني مختلف. المعامل الثالث هو حقل علم، ومنذ الإصدار v257 يمكنه أخذ القيمة 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.

تُعرّف حصة التخزين من حيث كتل القرص وفهارس العقد (inodes)، وفقًا لـ quotactl[10]. تأخذ حدًا مطلقًا للحجم بالبايت. إذا كانت القيمة متبوعة بـ K أو M أو G أو T، فسيُحلل الحجم المحدد على أنه كيلوبايت أو ميجابايت أو جيجابايت أو تيرابايت (بالأساس 1024) على التوالي. إذا حُدد حد مطلق للحجم، فستُضبط حصة الكتل فقط (مقربة لأقرب كتلة). بدلاً من ذلك، يمكن تحديد قيمة نسبوية، والتي تطبق نفس الحصة النسبوية على كل من الكتل وفهارس العقد. القيمة المبدئية هي إيقاف (off)، وفي هذه الحالة لن تُضبط أي حدود تخزين.

تُضبط الحدود الصارمة فقط، وليس الحدود المرنة. إذا كان نظام الملفات الأساسي للدلائل المحددة لا يدعم حصص المشروع، فلن تُضبط حدود التخزين المحددة. بالإضافة إلى تمكين الحصص لكل وحدة باستخدام هذه الإعدادات، من الضروري تمكين prjquota على مستوى نظام الملفات أيضًا (أي tune2fs -Q prjquota). يجب أيضًا تشغيل الحصص باستخدام quotaon.[11]

أُضيف في الإصدار 258.

لتعيين حصص القرص وفرضها، يجب تحديد StateDirectoryQuota= أو CacheDirectoryQuota= أو LogsDirectoryQuota=.

أُضيف في الإصدار 258.

إذا استُخدم DynamicUser= جنبًا إلى جنب مع ضبط RuntimeDirectoryPreserve= على قيم غير no، فإن المنطق يتغير قليلاً: تُنشأ دلائل RuntimeDirectory= أسفل /run/private/، وهو دليل مضيف يُجعل غير قابل للوصول للمستخِدمين غير ذوي الامتيازات، مما يضمن عدم إمكانية الوصول إلى هذه الدلائل من خلال إعادة تدوير معرف المستخدم الديناميكي. تُنشأ روابط رمزية لإخفاء هذا الاختلاف في السلوك. وبالتالي، تظهر الدلائل ذات الصلة دائمًا مباشرة أسفل /run/، سواء من منظور المضيف أو من داخل الوحدة.

أُضيف في الإصدارة 235.

أُضيف في الإصدارة 244.

المسارات المدرجة في ReadWritePaths= يمكن الوصول إليها من داخل نطاق الأسماء بنفس أوضاع الوصول كما من خارجه. المسارات المدرجة في ReadOnlyPaths= يمكن الوصول إليها للقراءة فقط، وستُرفض الكتابة حتى لو كانت ضوابط الوصول المعتادة للملف تسمح بذلك. يمكن تعشيش ReadWritePaths= داخل ReadOnlyPaths= لتوفير دلائل فرعية قابلة للكتابة داخل دلائل للقراءة فقط. استخدم ReadWritePaths= لإدراج مسارات معينة في القائمة المسموحة للوصول المكتوب إذا استُخدم ProtectSystem=strict. لاحظ أنه لا يمكن استخدام ReadWritePaths= للحصول على وصول مكتوب لنظام ملفات وُصلت كتلته الفائقة (superblock) بوضع القراءة فقط. في لينكس، يُمنح وصول الكتابة لكل نقطة وصل فقط إذا لم تكن نقطة الوصل نفسها و الكتلة الفائقة لنظام الملفات التي تدعمها مؤشرة بوضع القراءة فقط. يتحكم ReadWritePaths= في الأول فقط وليس الأخير، وبالتالي تظل الكتلة الفائقة لنظام الملفات للقراءة فقط محمية.

المسارات المدرجة في InaccessiblePaths= ستُجعل غير قابلة للوصول للعمليات داخل نطاق الأسماء جنبًا إلى جنب مع كل شيء أسفلها في هيكل نظام الملفات. قد يكون هذا أكثر تقييدًا مما هو مرغوب فيه، لأنه ليس من الممكن تعشيش ReadWritePaths= أو ReadOnlyPaths= أو BindPaths= أو BindReadOnlyPaths= داخلها. للحصول على خيار أكثر مرونة، انظر TemporaryFileSystem=.

المحتوى في المسارات المدرجة في NoExecPaths= ليس قابلاً للتنفيذ حتى لو كانت ضوابط الوصول المعتادة للملف تسمح بذلك. عشّش ExecPaths= داخل NoExecPaths= لتوفير محتوى قابل للتنفيذ داخل دلائل غير قابلة للتنفيذ.

يمكن تحديد مسارات ليست دلائل أيضًا. يمكن تحديد هذه الخيارات أكثر من مرة، وفي هذه الحالة سيكون لجميع المسارات المدرجة وصول محدود من داخل نطاق الأسماء. إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فستُصفّر القائمة المحددة، ولن يكون لجميع التعيينات السابقة أي مفعول.

المسارات في ReadWritePaths= و ReadOnlyPaths= و InaccessiblePaths= و ExecPaths= و NoExecPaths= يمكن أن تُسبق بـ "-"، وفي هذه الحالة سيُتجاهل وجودها إذا لم تكن موجودة. إذا سُبقت بـ "+" تؤخذ المسارات نسبة إلى الدليل الجذر للوحدة، كما هو مضبوط مع RootDirectory=/RootImage=، بدلاً من كونها نسبة إلى الدليل الجذر للمضيف (انظر أعلاه). عند الجمع بين "-" و "+" على المسار نفسه، تأكد من تحديد "-" أولاً، و "+" ثانياً.

لاحظ أن هذه الإعدادات ستفصل انتشار الوصولات (propagation of mounts) من عمليات الوحدة إلى المضيف. هذا يعني أنه لا يجوز استخدام هذا الإعداد للخدمات التي ينبغي أن تكون قادرة على تثبيت نقاط وصل في نطاق أسماء الوصل الرئيس. بالنسبة لـ ReadWritePaths= و ReadOnlyPaths=، لا يتأثر الانتشار في الاتجاه الآخر، أي أن الوصولات المنشأة على المضيف تظهر عمومًا في نطاق أسماء عمليات الوحدة، والوصولات المزالة على المضيف تختفي هناك أيضًا. على وجه الخصوص، لاحظ أن انتشار الوصل من المضيف إلى الوحدة سينتج عنه إنشاء وصولات غير معدلة في نطاق أسماء الوحدة، أي أن الوصولات القابلة للكتابة التي تظهر على المضيف ستكون قابلة للكتابة في نطاق أسماء الوحدة أيضًا، حتى عند انتشارها أسفل مسار مؤشر بـ ReadOnlyPaths=! وبالتالي فإن تقييد الوصول بهذه الخيارات لا يمتد إلى الوصولات الفرعية للدليل التي تُنشأ لاحقًا. هذا يعني أن الإغلاق الذي يقدمه هذا الإعداد ليس كاملاً، ولا يقدم حماية كاملة.

لاحظ أن مفعول هذه الإعدادات يمكن إبطاله بواسطة العمليات ذات الامتيازات. ولإعداد بيئة معزولة فعالة لوحدة ما، يُوصى بدمج هذه الإعدادات إما مع CapabilityBoundingSet=~CAP_SYS_ADMIN أو SystemCallFilter=~@mount.

يرجى توخي الحذر الشديد عند تطبيق هذه الخيارات على أنظمة ملفات واجهة برمجة التطبيقات (API) (يمكن العثور على قائمة بها في MountAPIVPS=)، نظرًا لأنها قد تكون مطلوبة لوظائف النظام الأساسية. علاوة على ذلك، يجب أن يكون /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.

إذا كان "true"، فستظل وحدة التخزين الخلفية للدلائل المؤقتة الخاصة على دلائل /tmp/ و /var/tmp/ للمضيف. ومن الممكن تشغيل وحدتين أو أكثر داخل نفس نطاق أسماء /tmp/ و /var/tmp/ الخاص باستخدام توجيه JoinsNamespaceOf=، انظر systemd.unit(5) للتفاصيل. هذا له تأثير جانبي يتمثل في إضافة اعتماديات Wants= و After= على جميع وحدات الوصل اللازمة للوصول إلى /tmp/ و /var/tmp/ على المضيف. علاوة على ذلك، يُضاف ترتيب After= ضمني على systemd-tmpfiles-setup.service(8).

إذا كان "disconnected"، فستُدعم الدلائل بواسطة مثيل tmpfs جديد تمامًا، مما يعني أن التخزين مفصول بالكامل عن نطاق أسماء المضيف. لا يُشارك مثيل tmpfs مع الوحدات الأخرى حتى لو استُخدم توجيه JoinsNamespaceOf=. إذا حُدد DefaultDependencies=no، ولم يُحدد RequiresMountsFor=/WantsMountsFor= لـ /var/، ولم يُحدد RootDirectory=/RootImage=، فسيُوصل نظام tmpfs جديد فقط على /tmp/، وبالتالي لا يزال دليل /var/tmp للمضيف قابلاً للوصول من الوحدة. في هذه الحالة، يُضبط متغير البيئة $TMPDIR على "/tmp" لاقتراح استخدام /tmp/ على العمليات في الوحدة. يضيف هذا آليًا اعتمادية WantsMountsFor=/var/، ما لم يُحدد DefaultDependencies=no و/أو RootDirectory=/RootImage=.

جدول 3. ملخص لـ PrivateTmp=disconnected

لاحظ أن تنفيذ هذا الإعداد قد يكون مستحيلاً (على سبيل المثال إذا كانت نطاقات أسماء الوصل غير متاحة)، ويجب كتابة الوحدة بطريقة لا تعتمد فقط على هذا الإعداد من أجل الأمان.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن PrivateUsers= ضمنيًا (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=").

سيؤدي تمكين هذا الخيار إلى تثبيت مرشح استدعاءات النظام لحظر استدعاءات نظام الإدخال/الإخراج منخفضة المستوى المجمعة في مجموعة @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 لربطه بنطاق أسماء الشبكة الجديد.

عند استخدام هذا الخيار على وحدة مقبس، فإن أي مقابس تُربط نيابة عن هذه الوحدة ستُربط داخل نطاق أسماء شبكة خاص. يمكن دمج هذا مع JoinsNamespaceOf= للاستماع على المقابس داخل نطاقات أسماء الشبكة للخدمات الأخرى.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن PrivateUsers= ضمنيًا (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=").

هذا الخيار متاح فقط لخدمات النظام.

أُضيف في الإصدار 259.

عند تمكين هذا الخيار، يكون PrivateMounts= ضمنيًا ما لم يُعطل صراحةً، وسيُعاد وصل /sys لربطه بنطاق أسماء الشبكة الجديد.

عند استخدام هذا الخيار على وحدة مقبس، فإن أي مقابس تُربط نيابة عن هذه الوحدة ستُربط داخل نطاق أسماء الشبكة المحدد.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن PrivateUsers= ضمنيًا (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=").

أُضيف في الإصدارة 242.

لاحظ أن نطاقات أسماء IPC ليس لها أثر على مقابس AF_UNIX، والتي تعد الشكل الأكثر شيوعًا لـ IPC المستخدم على لينكس. بدلًا من ذلك، تخضع مقابس AF_UNIX في نظام الملفات لنطاق أسماء الوصل، وتلك الموجودة في نطاق الأسماء المجرد تخضع لنطاق أسماء الشبكة. يؤثر نطاق أسماء IPC فقط على SysV 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.

لاحظ أن هذه الوظيفة قد لا تكون متوفرة، على سبيل المثال إذا كانت THP معطلة في النواة، أو إذا كانت النواة لا تدعم التحكم في THP على مستوى العملية عبر prctl(2).

أُضيف في الإصدار 260.

خيار PrivatePIDs= مدعوم فقط لوحدات الخدمة. هذا الضبط غير مدعوم مع Type=forking لأن النواة ستقتل جميع العمليات في نطاق أسماء PID إذا انتهت عملية init.

سيُتجاهل هذا الضبط إذا كانت النواة لا تدعم نطاقات أسماء PID.

لاحظ أن خدمات المستخدمين غير الممتلِكين للامتيازات (أي الخدمة التي تديرها نسخة مدير الخدمات الخاصة بكل مستخدم) ستفشل مع PrivatePIDs=yes إذا كان /proc/ مقنعًا (أي إذا وُصل /proc/kmsg بشكل متراكب باستخدام tmpfs كما يفعل systemd-nspawn(1)). يرجع هذا إلى قيد في النواة لا يسمح لنطاقات أسماء المستخدمين غير الممتلكين للامتيازات بوصل نسخة أقل قيودًا من /proc/.

أُضيف في الإصدار 257.

إذا كان المعامل هو "identity"، يُهيئ نطاق أسماء المستخدمين مع تخطيط مطابقة لأول 65536 من معرفات UIDs/GIDs. وأي معرفات UIDs/GIDs فوق 65536 ستُخطط إلى المستخدم والمجموعة "nobody" على التوالي. ومع أن هذا لا يوفر عزلًا لمعرفات UID/GID، نظرًا لاختيار جميع معرفات UIDs/GIDs بشكل متطابق، فإنه يوفر عزلًا لقدرات العملية، وبالتالي غالبًا ما يكون خيارًا جيدًا إذا كان نطاق أسماء المستخدمين المناسب مع خرائط UID متميزة غير ملائم.

إذا كان المعامل هو "full"، يُهيئ نطاق أسماء المستخدمين مع تخطيط مطابقة لكل معرفات UIDs/GIDs. بالإضافة إلى ذلك، بالنسبة لخدمات النظام، تتيح القيمة "full" للوحدة استدعاء نداءات النظام setgroups() (عبر ضبط /proc/pid/setgroups على "allow"). وعلى غرار "identity"، لا يوفر هذا عزلًا لمعرفات UID/GID، ولكنه يوفر عزلًا لقدرات العملية. إذا فُعِّل هذا الوضع، فستُشغل جميع عمليات الوحدة دون امتيازات في نطاق أسماء مستخدمي المضيف (بغض النظر عما إذا كان مستخدم/مجموعة الوحدة هو "root" أم لا). يعني هذا على وجه التحديد أن العملية ستكون لها قدرات عملية صفرية في نطاق أسماء مستخدمي المضيف، ولكن قدرات كاملة داخل نطاق أسماء مستخدمي الخدمة. وستؤثر الإعدادات مثل CapabilityBoundingSet= على الأخير فقط، ولا توجد طريقة لاكتساب قدرات إضافية في نطاق أسماء مستخدمي المضيف.

إذا كان المعامل هو "managed"، يُخصص نطاق عابر ومخصص ديناميكيًا مكون من 65536 من معرفات UIDs/GIDs للوحدة، ويُعين تخطيط UID/GID لعملية الوحدة بحيث يخطط معرف UID/GID 0 من داخل الوحدة إلى معرف UID/GID الأول من التخطيط المخصص. لاحظ أنه في هذا الوضع يختلف معرف UID/GID الذي ستعمل به عملية الخدمة اعتمادًا على ما إذا كان المنظور من جانب المضيف (حيث سيكون معرف UID مرتفعًا ومخصصًا ديناميكيًا) أو من داخل الوحدة (حيث سيكون 0). لاحظ أيضًا أن هذا الوضع سيفعل تخطيط UID لنظام الملفات لأنظمة الملفات التي تصل إليها هذه الخدمة، مما يخطط نطاق UID "الخارجي" على القرص إلى نطاق UID الديناميكي المحدد في وقت التشغيل.

عند إعداد هذا الضبط بواسطة نسخة مدير الخدمات الخاصة بكل مستخدم، يُحذف تخطيط مستخدم ومجموعة "root" إلى نفسه (ما لم يكن مدير المستخدم هو root). بالإضافة إلى ذلك، في حالة مدير نسخة كل مستخدم، سيُهيأ نطاق أسماء المستخدمين قبل معظم نطاقات الأسماء الأخرى. يعني هذا أن دمج PrivateUsers=true مع نطاقات أسماء أخرى سيتيح استخدام ميزات لا تدعمها عادة نسخ مدير الخدمات الخاصة بكل مستخدم.

هذا الضبط مفيد بشكل خاص بالاقتران مع RootDirectory=/RootImage=، حيث تقل الحاجة إلى مزامنة قواعد بيانات المستخدمين والمجموعات في الدليل الجذر وعلى المضيف، إذ إن المستخدمين والمجموعات الوحيدين الذين يجب مطابقتهم هم "root" و "nobody" ومستخدم ومجموعة الوحدة نفسها.

أُضيف في الإصدار 232.

لاحظ أن تطبيق هذا الضبط قد يكون مستحيلًا (على سبيل المثال إذا كانت نطاقات أسماء UTS غير متوفرة)، وينبغي كتابة الوحدة بطريقة لا تعتمد كليًا على هذا الضبط لتحقيق الأمان.

لاحظ أنه عند تفعيل هذا الخيار لخدمة ما، فإن تغييرات اسم المضيف لن تنتقل بعد الآن من النظام إلى الخدمة، وبالتالي فهو غير مناسب للخدمات التي تحتاج إلى ملاحظة تغييرات اسم مضيف النظام ديناميكيًا.

لاحظ أن هذا الخيار لا يمنع تغيير اسم مضيف النظام عبر hostnamectl. ومع ذلك، يمكن استخدام User= و Group= للتشغيل كمستخدم غير ممتلك للامتيازات لعدم السماح بتغيير اسم مضيف النظام. انظر SetHostname() في org.freedesktop.hostname1(5) لمزيد من التفاصيل.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن 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-bit 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.

بما أن عدد أنظمة الملفات الممكنة كبير، توجد مجموعات مسبقة التعريف لأنظمة الملفات. تبدأ المجموعة بالحرف "@"، يليه اسم المجموعة.

جدول 4. مجموعات أنظمة الملفات المعرفة مسبقًا حاليًا

استخدم أمر filesystems الخاص بأداة systemd-analyze(1) لجلب قائمة بأنظمة الملفات المعرفة على النظام المحلي.

لاحظ أن هذا الضبط قد لا يكون مدعومًا في بعض الأنظمة (على سبيل المثال إذا لم يكن خطاف LSM eBPF مفعلًا في النواة الأساسية أو إذا لم يكن تسلسل مجموعات التحكم الموحد مستخدمًا). وفي هذه الحالة لن يكون لهذا الضبط أي أثر.

لا يمكن تجاوز هذا الخيار ببدء مسار الملف التنفيذي بـ "+" في وحدة الخدمة، لأنه ينطبق على مجموعة التحكم بأكملها.

أُضيف في الإصدار 250.

مثال: إذا كانت الوحدة تحتوي على ما يلي،

RestrictNamespaces=cgroup ipc
RestrictNamespaces=cgroup net

عندئذٍ تُضبط cgroup و ipc و net. وإذا كانت السطر الثاني مسبوقًا بـ "~"، على سبيل المثال:

RestrictNamespaces=cgroup ipc
RestrictNamespaces=~cgroup net

عندئذٍ، تُضبط ipc فقط.

أُضيف في الإصدار 233.

إن تفويض أي نطاق أسماء باستخدام DelegateNamespaces= يتضمن ضُمنًا PrivateUsers=self ما لم يكن PrivateUsers= مفعلًا بالفعل صراحة بواسطة الوحدة. ولا يعني تفويض نطاق أسماء أن نطاق الأسماء قد أُلغي تشاركه، إذ يُجرى ذلك عبر الضبط الخاص بنطاق الأسماء في الوحدة مثل PrivateNetwork= أو PrivateMounts=.

لاحظ أن بعض خيارات عزل نطاقات الأسماء قد تستلزم نطاق أسماء وصل لنسخ واجهة برمجة التطبيقات VFS الخاصة، مثل PrivatePIDs= أو ProtectControlGroups=private/strict أو PrivateNetwork=. إذا فُعِّل أي من الخيارات المذكورة، فإن نطاق أسماء الوصل يُفوض ضُمنًا.

أُضيف في الإصدار 258.

يمكن استخدام هذا جنبًا إلى جنب مع ميزة تفويض bpffs لاختيار وظائف BPF المتاحة لعمليات الوحدة. عند وصل نظام ملفات BPF باستخدام واجهة برمجة التطبيقات fsopen()، يمكن تحديد أربعة خيارات وصل لضبط قائمة بأوامر وخرائط وبرامج وأنواع إرفاق BPF المسموح باستخدامها. تحتاج العمليات إلى الحصول على واصف ملف لنقطة وصل bpffs واستخدامه للحصول على رمز مميز يُفعل لنطاق أسماء المستخدمين هذا وظائف BPF المختارة عند وصل bpffs. يمكن العثور على شرح أكثر تفصيلًا لهذه الميزة في منشور LWN هذا[15].

أُضيف في الإصدار 258.

يتطلب أن يكون PrivateBPF=yes ليكون فعالًا، انظر PrivateBPF= لمزيد من التفاصيل.

أُضيف في الإصدار 258.

يتطلب أن يكون PrivateBPF=yes ليكون فعالًا، انظر PrivateBPF= لمزيد من التفاصيل.

أُضيف في الإصدار 258.

يتطلب أن يكون PrivateBPF=yes ليكون فعالًا، انظر PrivateBPF= لمزيد من التفاصيل.

أُضيف في الإصدار 258.

يتطلب أن يكون PrivateBPF=yes ليكون فعالًا، انظر PrivateBPF= لمزيد من التفاصيل.

أُضيف في الإصدار 258.

أُضيف في الإصدارة 235.

أُضيف في الإصدارة 231.

أُضيف في الإصدارة 231.

في الحالات الأخرى، تعود هذه التهيئة مبدئيًا إلى القيمة المعينة بواسطة DefaultRestrictSUIDSGID= في systemd-system.conf(5)، والتي تكون مطفأة مبدئيًا.

أُضيف في الإصدارة 242.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

أُضيف في الإصدار 232.

عند تشغيله، ينفذ ثلاث عمليات لكل عملية مُستدعاة: تُنشأ مساحة أسماء CLONE_NEWNS جديدة، وبعدها يُعاد وصل جميع الوصلات الموجودة إلى MS_SLAVE لتعطيل التوجيه من عمليات الوحدة إلى المضيف (مع ترك التوجيه في الاتجاه المعاكس ساري المفعول). وأخيرًا، يُعاد وصل الوصلات مجددًا إلى وضع التوجيه المتهيأ باستخدام MountFlags=، انظر أدناه.

تُضبط مساحات أسماء نظام ملفات بشكل فردي لكل عملية متفرعة يطلقها مدير الخدمة. بالتالي، فإن الوصلات المنشأة في مساحة أسماء العملية التي أنشأتها ExecStartPre= سوف تُنظّف آليًا بمجرد خروج تلك العملية، ولن تكون متاحة للعمليات اللاحقة المتفرعة لأجل 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 للوحدات، لأن هذا يعني أن الوصلات المؤقتة (مثل الوسائط القابلة للإزالة) للمضيف ستظل موصولة وبالتالي مشغولة إلى أجل غير مسمى في العمليات المتفرعة، حيث لن تستقبل مساحة أسماء نظام ملفات الوحدة أحداث توجيه الفصل.

عادةً، من الأفضل ترك هذا الإعداد دون تعديل، واستخدام خيارات مساحات أسماء نظام ملفات ذات المستوى الأعلى بدلًا منه، وتحديدًا PrivateMounts=، انظر أعلاه.

هذا الخيار متاح فقط لخدمات النظام، أو للخدمات التي تعمل في نماذج لكل مستخدم من مدير الخدمة وفي هذه الحالة يُمكّن PrivateUsers= ضمنيًا (يتطلب تمكين دعم مساحات أسماء المستخدمين غير الممتيزة في النواة عبر sysctl ‏"kernel.unprivileged_userns_clone=").

الأوامر المسبوقة بـ "+" لا تخضع للترشيح. تُدرج استدعاءات النظام execve() و exit() و exit_group() و getrlimit() و rt_sigreturn() و sigreturn() واستدعاءات النظام الخاصة بالاستعلام عن الوقت والنوم ضمنيًا في قائمة السماح ولا حاجة لإدراجها صراحةً.

الإجراء المبدئي عند رفض استدعاء النظام هو إنهاء العمليات باستخدام إشارة SIGSYS. يمكن تغيير هذا باستخدام SystemCallErrorNumber=، انظر أدناه. بالإضافة إلى ذلك، يمكن اختياريًا إلحاق استدعاءات النظام ومجموعات استدعاءات النظام المدرجة في قائمة المنع بنقطتين (":") ومعامل بنفس تنسيق SystemCallErrorNumber=، لاتخاذ هذا الإجراء عند إجراء استدعاء النظام المطابق. هذا له الأسبقية على الإجراء المحدد في SystemCallErrorNumber=.

تستخدم هذه الميزة واجهات وضع الحوسبة الآمنة 2 (Secure Computing Mode 2) للنواة ('ترشيح seccomp') وهي مفيدة لفرض بيئة عزل مخففة بأقل الحدود.

لاحظ أنه في الأنظمة التي تدعم واجهات تطبيق ثنائية (ABIs) متعددة (مثل x86/x86-64)، يوصى بإيقاف تشغيل واجهات ABI البديلة للخدمات، حتى لا يمكن استخدامها للتحايل على قيود هذا الخيار. وتحديدًا، يوصى بدمج هذا الخيار مع SystemCallArchitectures=native أو ما شابه ذلك.

لاحظ أن مرشحات استدعاءات النظام الصارمة قد تؤثر على مسارات برمجية التنفيذ ومعالجة الأخطاء عند استدعاء الخدمة. وتحديدًا، يلزم الوصول إلى استدعاء النظام execve() لتنفيذ ملف الخدمة الثنائي — وإذا حُظر فسيقود ذلك حتمًا إلى فشل استدعاء الخدمة. وأيضًا، إذا فشل تنفيذ ملف الخدمة الثنائي لسبب ما (على سبيل المثال: فقدان ملف الخدمة القابل للتنفيذ)، فقد يتطلب منطق معالجة الأخطاء الوصول إلى مجموعة إضافية من استدعاءات النظام من أجل معالجة هذا الفشل وتسجيله بشكل صحيح. قد يكون من الضروري تعطيل مرشحات استدعاءات النظام مؤقتًا للسماح بتنقيح مثل هذه الإخفاقات.

إذا حددت كلا نوعي هذا الخيار (أي قائمة السماح وقائمة المنع)، فإن أول ما يواجهه البرنامج سيكون له الأسبقية ويملي الإجراء المبدئي (إنهاء استدعاء النظام أو الموافقة عليه). ثم ستقوم الحالات التالية لهذا الخيار بإضافة أو حذف استدعاءات النظام المدرجة من مجموعة استدعاءات النظام المرشحة، اعتمادًا على نوعها والإجراء المبدئي. (على سبيل المثال، إذا بدأت بقاعدة قائمة سماح لـ read() و write()، وأضفت بعدها مباشرة قاعدة قائمة منع لـ write()، فسيُزال write() من المجموعة.)

بما أن عدد استدعاءات النظام الممكنة كبير، تُوفّر مجموعات مسبقة التعريف من استدعاءات النظام. تبدأ المجموعة بالمحرف "@"، يليه اسم المجموعة.

جدول 5. مجموعات استدعاءات النظام مسبقة التعريف حاليًا

لاحظ أنه مع إضافة استدعاءات نظام جديدة إلى النواة، قد تُضاف استدعاءات نظام إضافية إلى المجموعات المذكورة أعلاه. قد تتغير محتويات المجموعات أيضًا بين إصدارات systemd المختلفة. بالإضافة إلى ذلك، تعتمد قائمة استدعاءات النظام على إصدار النواة والبنية المعمارية التي جُمع systemd لأجلها. استخدم systemd-analyze syscall-filter لسرد القائمة الفعلية لاستدعاءات النظام في كل مرشح.

عمومًا، يُعد وضع استدعاءات النظام في قائمة السماح (بدلًا من قائمة المنع) هو وضع التشغيل الأكثر أمانًا. يوصى بفرض قوائم السماح باستدعاءات النظام لجميع خدمات النظام التي تعمل لفترات طويلة. وتحديدًا، تمثل السطور التالية خيارًا أساسيًا آمنًا نسبيًا لغالبية خدمات النظام:

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

لاحظ أن العديد من استدعاءات نظام النواة مُعرّفة بشكل مكرر الحشو: حيث توجد استدعاءات نظام متعددة لتنفيذ نفس العملية. على سبيل المثال، يمكن استخدام استدعاء النظام pidfd_send_signal() لتنفيذ عمليات مشابهة لما يمكن القيام به باستخدام استدعاء النظام الأقدم kill()، وبالتالي فإن حظر الأخير دون الأول يوفر حماية ضعيفة فقط. نظرًا لأن استدعاءات النظام الجديدة تُضاف بانتظام إلى النواة مع تقدم التطوير، فإن الحفاظ على شمولية قوائم منع استدعاءات النظام يتطلب عملًا مستمرًا. لذلك يوصى باستخدام قوائم السماح بدلاً من ذلك، والتي توفر ميزة حظر استدعاءات النظام الجديدة ضمنيًا بشكل مبدئي إلى أن تُحدّث قائمة السماح.

لاحظ أيضًا أنه يلزم توفير إمكانية الوصول إلى عدد من استدعاءات النظام لكي يعمل الرابط الديناميكي. الرابط الديناميكي مطلوب لتشغيل معظم البرامج العادية (تحديدًا: جميع ملفات ELF الثنائية الديناميكية، وهي الطريقة التي تبني بها معظم التوزيعات البرامج الحزمية). هذا يعني أن حظر استدعاءات النظام هذه (والتي تشمل open() أو openat() أو mmap()) سيجعل معظم البرامج المشحونة عادةً مع التوزيعات العامة غير قابلة للاستخدام.

يوصى بدمج الخيارات المتعلقة بوضع مساحات أسماء نظام ملفات مع SystemCallFilter=~@mount، وذلك لمنع عمليات الوحدة من التراجع عن الارتباطات. وتحديدًا هذه الخيارات هي: PrivateTmp= و PrivateDevices= و ProtectSystem= و ProtectHome= و ProtectKernelTunables= و ProtectControlGroups= و ProtectKernelLogs= و ProtectClock= و ReadOnlyPaths= و InaccessiblePaths= و ReadWritePaths=.

أُضيف في الإصدارة 187.

أُضيف في الإصدارة 209.

إذا استُخدم هذا الإعداد، فسيُسمح لعمليات هذه الوحدة فقط بإجراء استدعاءات النظام الأصلية (native)، واستدعاءات النظام للبنيات المعمارية المحددة. لأغراض هذا الخيار، تُعامل معمارية 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 غير المحاط بعلامات اقتباس[19]، ولكن على عكس الصدفة، تُحفظ المسافات البيضاء الداخلية وتُحفظ علامات الاقتباس التي تأتي بعد أول محرف غير مسافة بيضاء. تُهمَل المسافات البيضاء البادئة والختامية (المسافة، وعلامة الجدولة، وإرجاع العربة)، ولكن تُحفظ المسافات البيضاء الداخلية داخل السطر حرفيًا. السطر الذي ينتهي بخط مائل عكسي سيتصل بالسطر التالي، مع إهمال السطر الجديد نفسه. الخط المائل العكسي "\" المتبوع بأي محرف آخر غير السطر الجديد سيحفظ المحرف التالي، بحيث تصبح "\\" هي القيمة "\".

في الملف، يمكن للقيمة المحاطة بعلامة اقتباس مفردة "'" بعد علامة "=" أن تمتد عبر أسطر متعددة وأن تحتوي على أي محرف حرفيًا باستثناء علامة الاقتباس المفردة، مثل نص صدفة POSIX المحاط بعلامة اقتباس مفردة[20]. لا تُفسَّر أي تسلسلات هروب بالخط المائل العكسي. تُهمَل المسافات البيضاء البادئة والختامية خارج علامات الاقتباس المفردة.

في الملف، يمكن للقيمة المحاطة بعلامات اقتباس مزدوجة """ بعد علامة "=" أن تمتد عبر أسطر متعددة، وتُفسَّر نفس تسلسلات الهروب كما في نص صدفة POSIX المحاط بعلامات اقتباس مزدوجة[21]. الخط المائل العكسي ("\") المتبوع بأي من ""\`$" سيحفظ ذلك المحرف. الخط المائل العكسي المتبوع بسطر جديد يعد استمرارًا للسطر، ويُهمَل السطر الجديد نفسه. الخط المائل العكسي المتبوع بأي محرف آخر يُتجاهل؛ ويُحفظ كل من الخط المائل العكسي والمحرف التالي حرفيًا. تُهمَل المسافات البيضاء البادئة والختامية خارج علامات الاقتباس المزدوجة.

ينبغي أن يكون المعطى الممرر اسم ملف مطلق أو تعبير نمطي (wildcard). إذا كان الملف غير موجود، أو تعذرت قراءته، أو كان يحتوي على محتوى غير صالح، فستفشل الخدمة في البدء. لِجعل الملف اختياريًا، ابدأ المسار بعلامة "-"، مما يؤدي إلى تجاهل جميع الأخطاء المتعلقة بالملف بصمت. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُقرأ جميع الملفات المحددة. إذا أُسندت سلسلة نصية فارغة إلى هذا الخيار، فستُصفّر قائمة الملفات المراد قراءتها، وتصبح جميع التعيينات السابقة عديمة الأثر.

تُقرأ الملفات المدرجة في هذا التوجيه قبل وقت قصير من تنفيذ العملية (على وجه التحديد، بعد إنهاء جميع العمليات من حالة الوحدة السابقة. هذا يعني أنه يمكنك توليد هذه الملفات في حالة وحدة معينة، وقراءتها بهذا الخيار في الحالة التالية. تُقرأ الملفات من نظام ملفات مدير الخدمة، قبل حدوث أي تغييرات في نظام الملفات مثل عمليات الوصل المربوط bind mounts).

تتخطى الإعدادات القادمة من هذه الملفات الإعدادات المعينة باستخدام 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 في نظام الملفات، فسيُوصَل مقبس تدفق به. هذا الأخير مفيد لوصل الإدخال القياسي للعمليات بخدمات النظام الاختيارية.

خيار socket صالح في الخدمات المُفعلة بالمقابس فقط، ويتطلب أن يكون لملف وحدة المقبس ذات الصلة (انظر systemd.socket(5) للتفاصيل) إعداد Accept=yes، أو أن يحدد مقبسًا واحدًا فقط. إذا عُيّن هذا الخيار، فسيُوصَل الإدخال القياسي بالمقبس الذي أُنشطت الخدمة منه، وهو مفيد في المقام الأول للتوافق مع العفاريت (daemons) المصممة للاستخدام مع عفريت تنشيط المقابس التقليدي 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 (انظر أدناه) يُخزن ضمنيًا في السجل أيضًا، وبالتالي فإن الخيار المحدد المدرج أدناه هو مجموعة شاملة لهذا الخيار. (لاحظ أيضًا أن أي عفاريت syslog خارجية إضافية تتلقى بيانات سجلاتها من السجل أيضًا، وبالتالي فإن هذا هو الخيار المناسب للاستخدام عندما يراد معالجة التسجيل بواسطة هذا العفريت.)

يوصل الخيار kmsg الإخراج القياسي بمخزن سجل النواة المؤقت الذي يمكن الوصول إليه عبر dmesg(1)، بالإضافة إلى السجل. قد يكون عفريت السجل مضبوطًا لإرسال جميع السجلات إلى kmsg على أي حال، وفي هذه الحالة لا يختلف هذا الخيار عن journal.

يعمل الخياران journal+console و kmsg+console بطريقة مشابهة للخيارين أعلاه ولكنهما ينسخان الإخراج إلى محطة تحكم النظام (console) أيضًا.

يمكن استخدام الخيار file:path لوصل كائن نظام ملفات معين بالإخراج القياسي. الدلالات مشابهة لنفس الخيار في StandardInput=، انظر أعلاه. إذا كان path يشير إلى ملف عادي في نظام الملفات، فإنه يُفتح (ويُنشأ إذا لم يكن موجودًا بعد باستخدام امتيازات المستخدم الذي ينفذ عملية systemd) للكتابة في بداية الملف، ولكن دون اقتطاعه. إذا وُجّه الإدخال والإخراج القياسيان إلى نفس مسار الملف، فإنه يُفتح مرة واحدة فقط — للقراءة والكتابة معًا — ويُضاعَف واصف الملف. هذا مفيد بشكل خاص عندما يشير المسار المحدد إلى مقبس AF_UNIX في نظام الملفات، حيث لا يُنشأ في هذه الحالة سوى اتصال تدفق واحد لكل من الإدخال والإخراج.

الخيار append:path مشابه لـ file:path أعلاه، ولكنه يفتح الملف في وضع الإلحاق (append mode).

الخيار truncate:path مشابه لـ file:path أعلاه، ولكنه يقتطع الملف عند فتحه. بالنسبة للوحدات التي تحتوي على أسطر أوامر متعددة، مثل خدمات Type=oneshot التي تحتوي على خيارات ExecStart= متعددة، أو الخدمات التي تحتوي على ExecCondition= أو ExecStartPre= أو ExecStartPost=، يُعاد فتح ملف الإخراج وبالتالي يُعاد اقتطاعه لكل سطر أمر. إذا أُقتطع ملف الإخراج بينما لا يزال هناك عملية أخرى تفتح الملف، على سبيل المثال بواسطة 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[22]. لا تُفسَّر أي تسلسلات هروب أو محددات. تُتجاهل أي مسافة بيضاء في النسخة المرموزة أثناء فك الترميز.

لاحظ أن StandardInputText= و StandardInputData= يعملان على نفس مخزن البيانات المؤقت، ويمكن المزج بينهما لِضبط كل من البيانات الثنائية والنصية لنفس تدفق الإدخال. تُضم البيانات النصية أو الثنائية بدقة حسب ترتيب ظهور الإعدادات في ملف الوحدة. يؤدي إسناد سلسلة نصية فارغة لأي منهما إلى تصفير مخزن البيانات المؤقت.

يرجى الأخذ في الحسبان أنه من أجل الحفاظ على القراءة السهلة، يمكن تقسيم إعدادات ملف الوحدة الطويلة إلى أسطر متعددة، عن طريق تذييل كل سطر (باستثناء الأخير) بمحرف "\" (انظر systemd.unit(5) للتفاصيل). هذا مفيد بشكل خاص للبيانات الكبيرة المضبوطة بهذين الخيارين. مثال:

...
StandardInput=data
StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \


                  IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \


                  dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \


                  J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \


                  dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \


                  ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \


                  eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK
...

أُضيف في الإصدارة 236.

يمكن استخدام هذا الخيار لِضبط نظام التسجيل لإسقاط رسائل السجل الخاصة بخدمة معينة والتي تتجاوز المستوى المحدد. على سبيل المثال، عيّن LogLevelMax=info من أجل إيقاف تسجيل التنقيح لوحدة كثيرة الكلام بشكل خاص. بدلاً من ذلك، يمكن استخدام هذا الخيار لتمكين تسجيل إضافي حول وحدة معينة بواسطة عمليات مدير النظام أو المستخدم دون تغيير مستوى التسجيل العالمي لعمليات مدير النظام أو المستخدم، وذلك بتعيين LogLevelMax=debug.

لاحظ أن المستوى المضبوط يُطبَّق على أي رسائل سجل تكتبها أي من العمليات التابعة لهذه الوحدة، بالإضافة إلى أي رسائل سجل تكتبها عمليات مدير النظام أو المستخدم بالإشارة إلى هذه الوحدة، والمُرسلة عبر أي بروتوكول تسجيل مدعوم. يُطبَّق التخطي مبكرًا في أنبوب التسجيل، قبل إجراء أي نوع من المعالجة الإضافية. علاوة على ذلك، فإن الرسائل التي تمر عبر هذا المرشح بنجاح قد تُسقَط بواسطة مرشحات تُطبَّق في مرحلة لاحقة في نظام التسجيل الفرعي. على سبيل المثال، قد يمنع خيار MaxLevelStore= المضبوط في journald.conf(5) تخزين الرسائل ذات مستويات التسجيل الأعلى على القرص، على الرغم من أن LogLevelMax= الخاص بالوحدة قد سمح بمعالجتها.

أُضيف في الإصدارة 236.

لاحظ أن هذه الوظيفة متاحة حاليًا في خدمات النظام فقط، وليس في الخدمات الخاصة بكل مستخدم.

أُضيف في الإصدارة 236.

أُضيف في الإصدار 240.

نظرًا لأن المحرف "~" يُستخدم لتحديد الأنماط المرفوضة، فيجب استبداله بـ "\x7e" للسماح برسالة تبدأ بـ "~". على سبيل المثال، "~foobar" سيضيف نمطًا يطابق "foobar" إلى قائمة الرفض، بينما "\x7efoobar" سيضيف نمطًا يطابق "~foobar" إلى قائمة السماح.

تُختبر رسائل السجل مقابل الأنماط المرفوضة (إن وجدت)، ثم مقابل الأنماط المسموح بها (إن وجدت). إذا طابقت رسالة السجل أيًا من الأنماط المرفوضة، تُستبعد فورًا دون النظر إلى الأنماط المسموح بها. تُختبر رسائل السجل المتبقية مقابل الأنماط المسموح بها. وتُستبعد الرسائل التي لا تطابق أيًا من الأنماط المسموح بها. إذا لم تُحدَّد أنماط مسموح بها، تُعالج جميع الرسائل مباشرة بعد المرور عبر مرشحات الرفض.

تعتمد التصفية على الوحدة التي عُرّف لها LogFilterPatterns=، مما يعني أن رسائل السجل القادمة من systemd(1) حول الوحدة لا تُؤخذ في الحسبان. لن تُوجّه رسائل السجل المصفاة إلى عفاريت syslog التقليدية، أو مخزن سجل النواة المؤقت (kmsg)، أو محطة تحكم systemd، ولن تُرسل كرسائل حائط (wall messages) إلى جميع المستخدمين المسجلين دخولهم.

لاحظ أن هذه الوظيفة متاحة حاليًا في خدمات النظام فقط، وليس في الخدمات الخاصة بكل مستخدم.

أُضيف في الإصدار 253.

داخليًا، تُنفَّذ مساحات اسم السجل من خلال مساحات اسم الوصل في لينكس (Linux mount namespacing) وفوق الوصل (over-mounting) للدليل الذي يحتوي على مقابس AF_UNIX ذات الصلة والمستخدمة للتسجيل في مساحة اسم الوصل الخاصة بالوحدة. نظرًا لاستخدام مساحات اسم الوصل، فإن هذا الإعداد يفصل انتشار عمليات الوصل من عمليات الوحدة إلى المضيف، بشكل مشابه لكيفية عمل ReadOnlyPaths= والإعدادات المماثلة الموصوفة أعلاه. وبالتالي، لا يجوز استخدام مساحات اسم السجل للخدمات التي تحتاج إلى إنشاء نقاط وصل على المضيف.

عند استخدام هذا الخيار، ستكتسب الوحدة آليًا اعتماديات ترتيب ومتطلبات على وحدتي المقبس المرتبطتين بمثيل systemd-journald@.service بحيث تُنشأ آليًا قبل بدء تشغيل الوحدة. لاحظ أنه عند استخدام هذا الخيار، لا يظهر مخرج السجل لهذه الخدمة في مخرج journalctl(1) العادي، ما لم يُستخدَم خيار --namespace=.

يتوفر هذا الخيار لخدمات النظام فقط وغير مدعوم للخدمات التي تعمل في حالات تخص المستخدم لمدير الخدمة.

أُضيف في الإصدار 245.

أُضيف في الإصدار 250.

يأخذ إعداد LoadCredential= معرفًا نصيًا (ID) لِيُستخدم كاسم لوثيقة الاستيثاق بالإضافة إلى مسار نظام ملفات، يفصل بينهما نقطتان رئيستان. يجب أن يكون المعرف سلسلة نصية قصيرة من ترميز ASCII مناسبة كاسم ملف في نظام الملفات، ويمكن للمستخدم اختيارها بحرية. إذا كان المسار المحدد مطلقًا، فإنه يُفتح كملف عادي وتُقرأ بيانات وثيقة الاستيثاق منه. إذا كان المسار المطلق يشير إلى مقبس تدفق AF_UNIX في نظام الملفات، فسيُنشأ اتصال به (مرة واحدة عند استدعاء العملية) وتُقرأ بيانات وثيقة الاستيثاق من الاتصال، مما يوفر نقطة تكامل IPC سهلة لنقل وثائق الاستيثاق ديناميكيًا من الخدمات الأخرى.

إذا لم يكن المسار المحدد مطلقًا وكان هو بحد ذاته مؤهلًا كمُعرِّف اعتماد صالح، يُحاول العثور على اعتماد استلمه مدير الخدمة نفسه تحت الاسم المحدد — وهو ما يمكن استخدامه لنشر الاعتمادات من بيئة استدعاء (مثال: مدير حاويات استدعى مدير الخدمة) إلى داخل خدمة. إذا لم يُعثر على أي اعتماد مُمرَّر مطابق، سيقوم مدير خدمات النظام بالبحث في الأدلة /etc/credstore/، و/run/credstore/، و/usr/lib/credstore/ عن ملفات تحت اسم الاعتماد — وهي بالتالي مواقع موصى بها لبيانات الاعتماد على القرص. إذا استُخدم LoadCredentialEncrypted=، فسيُبحث في /run/credstore.encrypted/، و/etc/credstore.encrypted/، و/usr/lib/credstore.encrypted/ أيضًا. سيقوم مدير الخدمة لكل مستخدم بالبحث في $XDG_CONFIG_HOME/credstore/، و$XDG_RUNTIME_DIR/credstore/، و$HOME/.local/lib/credstore/ (والنظائر التي تنتهي بـ .../credstore.encrypted/) بدلًا من ذلك. يمكن استخدام الأداة systemd-path(1) للاستعلام عن مسار البحث الدقيق لمخزن الاعتمادات.

إذا حُذف مسار نظام الملفات، فيُختار مطابقًا لاسم الاعتماد، أي أن هذه طريقة موجزة للتصريح عن اعتمادات لتوريثها من مدير الخدمة أو أدلة credstore إلى داخل خدمة. يمكن استخدام هذا الخيار مرات متعددة، مع تعريف اعتماد إضافي في كل مرة لتمريره إلى الوحدة.

لاحظ أنه إذا لم يُحدد المسار أو أُعطي مُعرِّف اعتماد صالح، أي في الحالتين أعلاه، فلا يُعتبر فقدان الاعتماد أمرًا حاسمًا.

إذا حُدد مسار مطلق يشير إلى دليل، فسيُحمَّل كل ملف في ذلك الدليل (بشكل متكرر) كاعتماد منفصل. سيكون مُعرِّف كل اعتماد هو المُعرِّف المُقدَّم متبوعًا بـ "_$FILENAME" (مثال: "Key_file1"). عند التحميل من دليل، ستُتجاهل الروابط الرمزية.

قد تكون محتويات الملف/المقبس بيانات ثنائية أو نصية اعتباطية، بما في ذلك محارف الأسطر الجديدة وبايتات NUL.

إعداد LoadCredentialEncrypted= مطابق لـ LoadCredential=، باستثناء أن بيانات الاعتماد تُفك تعميتها وتُستوثق قبل تمريرها إلى العمليات المنفذة. تحديدًا، يجب أن يشير المسار المرجعي إلى ملف أو مقبس به اعتماد مُعمَّى، كما هو مطبق بواسطة systemd-creds(1). يُحمَّل هذا الاعتماد، وتُفك تعميته، وتُستوثق، ثم يُمرَّر إلى التطبيق في صورة نص صريح، بنفس الطريقة التي يُمرَّر بها اعتماد عادي محدد عبر LoadCredential=. الاعتماد المُكوَّن بهذه الطريقة قد يُعمَّى/يُستوثق بشكل متناظر باستخدام مفتاح سري مُشتق من شريحة أمن TPM2 الخاصة بالنظام، أو بمفتاح سري مخزن في /var/lib/systemd/credential.secret، أو بكليهما. استخدام اعتمادات مُعمَّاة ومُستوثقة يُحسِّن الأمن لأن الاعتمادات لا تُخزَّن كنص صريح ولا تُستوثق وتُفك تعميتها إلى نص صريح إلا في اللحظة التي تُبدأ فيها الخدمة التي تتطلبها. علاوة على ذلك، قد تُربط الاعتمادات بالعتاد والتثبيتات المحلية، بحيث لا يمكن تحليلها بسهولة دون اتصال، أو توليدها خارجيًا. طالع systemd.resource-control(5) للحصول على تفاصيل حول DevicePolicy= أو DeviceAllow=.

لاحظ أن الاعتمادات المُعمَّاة الموجهة لخدمات مدير الخدمة لكل مستخدم يجب أن تُعمَّى باستخدام systemd-creds encrypt --user، وتلك الخاصة بمدير خدمات النظام بدون مفتاح --user. الاعتمادات المُعمَّاة تكون دائمًا موجهة لمستخدم معين أو للنظام ككل، ويُضمن أن مديري خدمات لكل مستخدم لا يمكنهم فك تعمية الأسرار المخصصة للنظام أو لمستخدمين آخرين.

يجب أن تكون ملفات الاعتماد/مقابس IPC متاحة لمدير الخدمة، ولكن لا يلزم أن تكون متاحة مباشرة لعمليات الوحدة: بيانات الاعتماد تُقرأ وتُنسخ إلى نسخ منفصلة للقراءة فقط للوحدة تكون متاحة للعمليات ذات الصلاحيات المناسبة. هذا مفيد بشكل خاص عند دمجه مع DynamicUser= حيث يمكن بهذه الطريقة إتاحة البيانات ذات الصلاحيات للعمليات التي تعمل تحت معرف مستخدم (UID) ديناميكي (أي غير معروف مسبقًا) دون الحاجة لفتح الوصول لجميع المستخدمين.

للإشارة إلى المسار الذي يمكن قراءة اعتماد منه داخل سطر أوامر ExecStart= استخدم "${CREDENTIALS_DIRECTORY}/mycred"، مثال: "ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred". للإشارة إلى المسار الذي يمكن قراءة اعتماد منه داخل سطر Environment= استخدم "%d/mycred"، مثال: "Environment=MYCREDPATH=%d/mycred". بالنسبة لخدمات النظام، يمكن أيضًا الإشارة إلى المسار كـ "/run/credentials/UNITNAME" في الحالات التي لا يكون فيها الاستيفاء ممكنًا، مثال: ملفات إعداد برمجيات لا تدعم الاعتمادات أصليًا بعد. يُعتبر $CREDENTIALS_DIRECTORY الواجهة الرئيسية للبحث عن الاعتمادات، مع ذلك، لأنه يعمل أيضًا لخدمات المستخدم.

حاليًا، يُفرض حد أقصى متراكم لحجم الاعتماد يبلغ 1 ميجابايت لكل وحدة.

قد يتلقى مدير الخدمة نفسه اعتمادات نظام يمكن نشرها للخدمات من مدير حاوية مستضيف أو مُراقب آلة افتراضية (VM hypervisor). طالع وثائق Container Interface[23] للحصول على تفاصيل حول الأول. بالنسبة للأخير، مرِّر مدخلات جدول سلاسل OEM DMI/SMBIOS[24] (نوع الحقل 11) مع بادئة "io.systemd.credential:" أو "io.systemd.credential.binary:". في كلتا الحالتين، يُتوقع زوج مفتاح/قيمة مفصول بـ "=". في الحالة الأخيرة، يُفك ترميز الجانب الأيمن بـ Base64 عند التحليل (مما يسمح بتمرير بيانات ثنائية). مثال لمفتاح qemu[25]: "-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[26].

أُضيف في الإصدار 247.

يطبق تعبير النمط مجموعة فرعية تقييدية من glob(7): يمكن تحديد محرف بدل "*" واحد فقط في النهاية. لا يُسمح بمحرفي البدل "?" و "[]"، كما لا يُسمح بمحارف البدل "*" في أي مكان باستثناء نهاية تعبير النمط.

اختياريًا، يمكن أن يتبع اسم الاستيثاق أو النمط نقطتان متبوعتان بنمط إعادة تسمية. إذا حُدّد، تُعاد تسمية جميع الاستيثاقات المطابقة لاسم الاستيثاق أو النمط وفقًا لنمط معين. على سبيل المثال، إذا حُدّد "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=.

لاحظ أنه إذا فشلت عملية فك التعمية أو الاستيثاق لاستيثاق التُقط كنتيجة لـ ImportCredential=، فسيُتخطى بلطف (يُنشأ تحذير، ولكن لن يُجعل الاستيثاق متاحًا للخدمة المستدعاة). يختلف هذا عن تلك المُهيئة عبر SetCredentialEncrypted=/LoadCredentialEncrypted=، حيث سيؤدي فشل فك التعمية/الاستيثاق إلى فشل الخدمة.

أُضيف في الإصدار 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