SYSTEMD.EXEC(5)

الاسم
systemd.exec - تهيئة بيئة التنفيذ

موجز

service.service, socket.socket, mount.mount, swap.swap

الوصف

تتشارك ملفات تهيئة الوحدات الخاصة بالخدمات والمقابس ونقاط الوصل وأجهزة التبديل في مجموعة فرعية من خيارات التهيئة التي تحدد بيئة تنفيذ العمليات المولدة.

تسرد صفحة الدليل هذه خيارات التهيئة المشتركة بين أنواع الوحدات الأربعة هذه. انظر systemd.unit(5) للخيارات المشتركة لجميع ملفات تهيئة الوحدات، و systemd.service(5)، و systemd.socket(5)، و systemd.swap(5)، و systemd.mount(5) لمزيد من المعلومات حول ملفات تهيئة الوحدات المحددة. وتُهيأ خيارات التهيئة الخاصة بالتنفيذ في أقسام [Service] أو [Socket] أو [Mount] أو [Swap]، اعتمادًا على نوع الوحدة.

بالإضافة إلى ذلك، تُسرد الخيارات التي تتحكم في الموارد من خلال مجموعات تحكم لينكس (cgroups) في systemd.resource-control(5). وتكمل تلك الخيارات الخيارات المدرجة هنا.

اعتماديات ضمنية

تؤدي بعض معلمات التنفيذ إلى إضافة اعتماديات إضافية آليًا:

    • الوحدات التي عُيّن لها WorkingDirectory= أو RootDirectory= أو RootImage= أو RuntimeDirectory= أو StateDirectory= أو CacheDirectory= أو LogsDirectory= أو ConfigurationDirectory= تكتسب آليًا اعتماديات من النوع Requires= و After= على جميع وحدات الوصل المطلوبة للوصول إلى المسارات المحددة. هذا يعادل إدراجها صراحة في RequiresMountsFor=.

    • الوحدات التي تستخدم PrivateTmp=yes تكتسب آليًا اعتماديات من نوع Wants= و After= على جميع عمليات الوصل المطلوبة للوصول إلى /tmp/ و /var/tmp/ واعتمادية After= آلية على systemd-tmpfiles-setup.service(8)، ما لم يُحدد DefaultDependencies=no. إذا حُدد DefaultDependencies=no ولم يُحدد RequiresMountsFor=/tmp/ أو WantsMountsFor=/tmp/ أو After=tmp.mount أو RootDirectory=/RootImage=، فتُحوّل PrivateTmp=yes إلى PrivateTmp=disconnected.

    • الوحدات التي تستخدم PrivateTmp=disconnected تكتسب آليًا اعتماديات من نوع Wants= و After= على الوصل المطلوب للوصول إلى /var/، ما لم يُحدد DefaultDependencies=no و/أو RootDirectory=/RootImage=. إذا حُدد DefaultDependencies=no ولم يُحدد RequiresMountsFor=/var/ أو WantsMountsFor=/var/ أو After=var.mount أو RootDirectory=/RootImage=، فيُعاد استخدام الوصل الخاص على /tmp/ من أجل /var/tmp/ عبر تعيين $TMPDIR بشكل مناسب.

    • الوحدات التي يتصل مخرجها القياسي أو مخرج الخطأ فيها بـ journal أو kmsg (أو توليفاتها مع مخرج الطرفية، انظر أدناه) تكتسب آليًا اعتماديات من نوع After= على systemd-journald.socket.

    • الوحدات التي تستخدم LogNamespace= ستكتسب آليًا اعتماديات ترتيب ومتطلبات على وحدتي المقبس المرتبطتين بنماذج systemd-journald@.service.

المسارات

يمكن استخدام الإعدادات التالية لتغيير منظور الخدمة لنظام الملفات. يرجى ملاحظة أن المسارات يجب أن تكون مطلقة وألا تحتوي على جزء مسار "..".

ExecSearchPath=
    يأخذ قائمة مفصولة بنقطتين رأسيتين من المسارات المطلقة التي يمكن العثور فيها على الملف التنفيذي المستخدم بواسطة خصائص Exec*= (مثل ExecStart= و ExecStop= وما إلى ذلك). يتخطى ExecSearchPath= المتغير $PATH إذا لم يوفره المستخدم من خلال Environment= أو EnvironmentFile= أو PassEnvironment=. يؤدي تعيين سلسلة نصية فارغة إلى إزالة التعيينات السابقة، ويؤدي تعيين ExecSearchPath= إلى قيمة عدة مرات إلى الإلحاق بالإعداد السابق.

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

WorkingDirectory=
    يأخذ مسار دليل نسبيًا إلى دليل الجذر الخاص بالخدمة والمحدد بواسطة RootDirectory=، أو القيمة الخاصة "~". يحدد دليل العمل للعمليات المنفذة. إذا عُيّن إلى "~"، فيُستخدم الدليل المنزلي للمستخدم المحدد في User=. إذا لم يُحدد، فإنه يؤول مبدئيًا إلى دليل الجذر عندما يعمل systemd كنموذج نظام، وإلى الدليل المنزلي للمستخدم المعني إذا دُور كمستخدم. إذا بُدئ الإعداد بحرف "-"، فلا يُعد غياب دليل العمل أمرًا مهلكًا. إذا لم يُعين RootDirectory=/RootImage=، فإن WorkingDirectory= يكون نسبيًا لجذر النظام الذي يدير مدير الخدمة. لاحظ أن تعيين هذه المعلمة قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

RootDirectory=
    يأخذ مسار دليل نسبيًا إلى دليل جذر المضيف (أي جذر النظام الذي يدير مدير الخدمة). ويحدد دليل الجذر للعمليات المنفذة، باستخدام استدعاء النظام pivot_root(2) أو chroot(2). إذا استُخدم هذا، فيجب التأكد من أن الملف التنفيذي للعملية وجميع ملفاته المساعدة متاحة في الجذر الجديد. لاحظ أن تعيين هذه المعلمة قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

    يُعد الإعدادان 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=").

RootImage=
    يأخذ مسارًا إلى عقدة جهاز كتلي أو ملف عادي كمعامل. هذا الاستدعاء مشابه لـ RootDirectory= ولكنه يوصل هرمية نظام ملفات من عقدة جهاز كتلي أو ملف عروة ارتجاعية بدلاً من دليل. يجب أن تحتوي عقدة الجهاز أو ملف صورة نظام الملفات على نظام ملفات بدون جدول أقسام، أو نظام ملفات داخل جدول أقسام MBR/MS-DOS أو GPT يحتوي على قسم واحد متوافق مع لينكس فقط، أو مجموعة من أنظمة الملفات داخل جدول أقسام GPT يتبع UAPI.2 Discoverable Partitions Specification[1].

    عندما يُعين 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.

RootImageOptions=
    يأخذ قائمة مفصولة بفاصلة من خيارات الوصل التي ستُستخدم في صور الأقراص المحددة بواسطة RootImage=. اختياريًا، يمكن بدء الاسم باسم قسم، متبوعًا بنقطتين رأسيين، في حال كانت الصورة تحتوي على أقسام متعددة، وإلا فإن اسم القسم "root" هو المفهوم ضمنيًا. يمكن تحديد خيارات لأقسام متعددة في سطر واحد بفاصل مسافات. يؤدي تعيين سلسلة نصية فارغة إلى إزالة التعيينات السابقة. للحصول على قائمة بخيارات الوصل الصالحة، يرجى الرجوع إلى mount(8).

    تتبع أسماء الأقسام الصالحة مواصفة 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.

RootEphemeral=
    يأخذ معاملًا منطقيًا. في حال تمكينه، ستعمل العمليات المنفذة في نسخة زائلة من دليل الجذر أو صورة الجذر. توضع النسخة الزائلة في /var/lib/systemd/ephemeral-trees/ أثناء نشاط الخدمة وتُنظّف عند إيقاف الخدمة أو إعادة تشغيلها. إذا استُخدم RootDirectory= وكان دليل الجذر حجمًا فرعيًا، فستُنشأ النسخة الزائلة عن طريق أخذ لقطة للحجم الفرعي.

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

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

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

RootHash=
    يأخذ مفروم جذر لسلامة البيانات (dm-verity) محددًا بالنظام الست عشري، أو مسار ملف يحتوي على مفروم جذر بتنسيق ست عشري ASCII. يُمكّن هذا الخيار عمليات التحقق من سلامة البيانات باستخدام dm-verity، إذا كانت الصورة المستخدمة تحتوي على بيانات السلامة المناسبة (انظر أعلاه) أو إذا استُخدم RootVerity=. يجب أن يطابق المفروم المحدد مفروم الجذر لبيانات السلامة، وعادةً ما يكون طوله 256 بت على الأقل (وبالتالي 64 محرفًا ست عشريًا منسقًا) (في حالة SHA256 على سبيل المثال). إذا لم يُحدد هذا الخيار، ولكن ملف الصورة يحمل سمة الملف الموسعة "user.verity.roothash" (انظر xattr(7))، فيُقرأ مفروم الجذر منها، كأحرف ست عشرية منسقة أيضًا. إذا لم تُعثر على سمة الملف الموسعة (أو كانت غير مدعومة من نظام الملفات الأساسي)، ولكن عُثر على ملف ذي اللاحقة .roothash بجوار ملف الصورة، ويحمل نفس الاسم (إلا إذا كانت الصورة ذات اللاحقة .raw، وفي هذه الحالة يجب ألا يحتوي اسم ملف مفروم الجذر عليها)، فيُقرأ مفروم الجذر منه ويُستخدم آليًا، كأحرف ست عشرية منسقة أيضًا.

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

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

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

RootHashSignature=
    يأخذ توقيع PKCS7 لخيار RootHash= كمسار لملف توقيع مرمّز بـ DER، أو كسلسلة نصية ASCII مرمّزة بـ base64 لتوقيع مرمّز بـ DER مسبوق بـ "base64:". لن يُفتح حجم dm-verity إلا إذا كان توقيع مفروم الجذر صالحًا وموقعًا بواسطة مفتاح عام موجود في حلقة مفاتيح النواة. إذا لم يُحدد هذا الخيار، ولكن عُثر على ملف ذي اللاحقة .roothash.p7s بجوار ملف الصورة، ويحمل نفس الاسم (إلا إذا كانت الصورة ذات اللاحقة .raw، وفي هذه الحالة يجب ألا يحتوي اسم ملف التوقيع عليها)، فيُقرأ التوقيع منه ويُستخدم آليًا.

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

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

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

RootVerity=
    يأخذ مسار ملف سلامة البيانات (dm-verity). يُمكّن هذا الخيار عمليات التحقق من سلامة البيانات باستخدام dm-verity، إذا استُخدم RootImage= ومُرّر مفروم جذر وإذا كانت الصورة المستخدمة نفسها لا تحتوي على بيانات السلامة. يجب أن يتطابق مفروم الجذر مع بيانات السلامة. إذا لم يُحدد هذا الخيار، ولكن عُثر على ملف ذي اللاحقة .verity بجوار ملف الصورة، ويحمل نفس الاسم (إلا إذا كانت الصورة ذات اللاحقة .raw، وفي هذه الحالة يجب ألا يحتوي اسم ملف بيانات verity عليها)، فيُقرأ بيانات verity منه وتُستخدم آليًا.

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

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

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

RootImagePolicy=، و MountImagePolicy=، و ExtensionImagePolicy=
    يأخذ سلسلة سياسة الصورة وفقًا لـ systemd.image-policy(7) لاستخدامها عند وصل صور الأقراص (DDI) المحددة في RootImage= و MountImage= و ExtensionImage= على التوالي. إذا لم تُحدد، فإن سلسلة السياسة التالية هي المبدئية لـ RootImagePolicy= و MountImagePolicy:

        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.

RootMStack=
    يأخذ مسارًا إلى دليل systemd.mstack(7) يغلف مكدس وصل يتكون من طبقات وعمليات وصل ملزمة. على غرار RootDirectory= و RootImage=، فإن هذا يشغل الخدمة من نظام ملفات جذر متميز، وفي هذه الحالة يُعد عبر "overlayfs".

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

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

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

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

MountAPIVFS=
    يأخذ معاملًا منطقيًا. في حال تشغيله، تُنشأ مساحة اسم وصل خاصة لعمليات الوحدة وتُوصل أنظمة ملفات واجهة برمجة التطبيقات /proc/ و /sys/ و /dev/ و /run/ (كـ "tmpfs" فارغ) بداخلها، ما لم تكن موصلة بالفعل. لاحظ أن هذا الخيار ليس له تأثير ما لم يُستخدم بالاقتران مع RootDirectory=/RootImage= لأن عمليات الوصل الأربعة هذه تُوصل عمومًا في المضيف على أي حال، وما لم يتغير دليل الجذر، فستكون مساحة اسم الوصل الخاصة نسخة 1:1 من المضيف، وتتضمن عمليات الوصل الأربعة هذه. لاحظ أن نظام ملفات /dev/ للمضيف يُوصل ربطًا إذا استُخدم هذا الخيار بدون PrivateDevices=. لتشغيل الخدمة مع نسخة خاصة وبسيطة من /dev/، اجمع بين هذا الخيار و PrivateDevices=.

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

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

BindLogSockets=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا، فستُوصل المقابس من systemd-journald.socket(8) ربطًا في مساحة اسم الوصل. هذا مفيد بشكل خاص عند استخدام نموذج مختلف من /run/، للتأكد من أن العمليات التي تعمل في مساحة الاسم لا تزال قادرة على استخدام sd-journal(3).

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

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

ProtectProc=
    يأخذ أحد القيم "noaccess" أو "invisible" أو "ptraceable" أو "default" (وهي القيمة المبدئية). عند تعيينه، فإنه يتحكم في خيار الوصل "hidepid=" لنموذج "procfs" للوحدة والذي يتحكم في أي الأدلة التي تحتوي على معلومات واصفة للعملية (/proc/PID) تكون مرئية ويمكن الوصول إليها: عند تعيينه على "noaccess"، تُسلب القدرة على الوصول إلى معظم المعلومات الواصفة لعمليات المستخدمين الآخرين في /proc/ لعمليات الخدمة. عند تعيينه على "invisible"، تُخفى العمليات المملوكة لمستخدمين آخرين من /proc/. إذا كان "ptraceable"، فإن جميع العمليات التي لا يمكن تتبعها بواسطة ptrace() لعملية ما تُخفى عنها. إذا كان "default"، فلا تُفرض أي قيود على الوصول إلى /proc/ أو رؤيته. لمزيد من التفاصيل، انظر The /proc Filesystem[3]. يوصى عمومًا بتشغيل معظم خدمات النظام مع تعيين هذا الخيار على "invisible". يُنفّذ هذا الخيار عبر مساحات أسماء نظام الملفات، وبالتالي لا يمكن استخدامه مع الخدمات التي يجب أن تكون قادرة على تثبيت نقاط وصل في هرمية نظام ملفات المضيف. لاحظ أن المستخدم الجذر لا يتأثر بهذا الخيار، لذا لكي يكون فعالاً يجب استخدامه مع User= أو DynamicUser=yes، وأيضًا بدون قدرة "CAP_SYS_PTRACE"، والتي تسمح أيضًا للعملية بتجاوز هذه الميزة. لا يمكن استخدامه للخدمات التي تحتاج إلى الوصول إلى معلومات واصفة حول عمليات المستخدمين الآخرين. يتضمن هذا الخيار ضمنيًا MountAPIVFS=.

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

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

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

ProcSubset=
    يأخذ أحد الخيارين "all" (المبدئي) و "pid". إذا كان "pid"، فإن جميع الملفات والأدلة غير المرتبطة مباشرة بإدارة العمليات واستبطانها تُجعل غير مرئية في نظام ملفات /proc/ المهيأ لعمليات الوحدة. هذا يتحكم في خيار الوصل "subset=" لنموذج "procfs" للوحدة. لمزيد من التفاصيل، انظر The /proc Filesystem[3]. لاحظ أن لينكس يعرض واجهات برمجة تطبيقات مختلفة للنواة عبر /proc/، والتي تُجعل غير متاحة بهذا الإعداد. نظرًا لأن واجهات برمجة التطبيقات هذه تُستخدم بشكل متكرر، فإن هذا الخيار مفيد فقط في حالات قليلة محددة، وغير مناسب لمعظم البرامج غير البسيطة.

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

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

BindPaths=, BindReadOnlyPaths=
    يُهيئ عمليات الوصل الملزمة الخاصة بالوحدة. يجعل الوصل الملزم ملفًا أو دليلاً معينًا متاحًا في مكان إضافي في منظور الوحدة لنظام الملفات. أي عمليات وصل ملزمة تُنشأ بهذا الخيار تكون خاصة بالوحدة، وغير مرئية في جدول وصل المضيف. يتوقع هذا الخيار قائمة مفصولة بمسافات بيضاء من تعريفات الوصل الملزم. يتكون كل تعريف من ثلاثية مفصولة بنقطتين رأسيتين من مسار المصدر ومسار الوجهة وسلسلة خيارات، حيث يكون الأخيران اختياريين. إذا حُدد مسار المصدر فقط، فيُعتبر المصدر والوجهة متطابقين. قد تكون سلسلة الخيارات إما "rbind" أو "norbind" لتهيئة وصل ملزم عاود أو غير عاود. إذا حُذف مسار الوجهة، فيجب حذف سلسلة الخيارات أيضًا. قد يُسبق كل تعريف وصل ملزم بـ "-"، وفي هذه الحالة سيُتجاهل عندما يكون مسار مصدره غير موجود أو لا يمكن الوصول إليه.

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

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

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

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

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

MountImages=
    هذا الإعداد مشابه لـ RootImage= من حيث إنه يوصل هرمية نظام ملفات من عقدة جهاز كتلي أو ملف عروة ارتجاعية، ولكن يمكن تحديد دليل الوجهة بالإضافة إلى خيارات الوصل. يتوقع هذا الخيار قائمة مفصولة بمسافات بيضاء من تعريفات الوصل. يتكون كل تعريف من صف مفصول بنقطتين رأسيين من مسار المصدر وتعاريف الوجهة، متبوعًا اختياريًا بنقطتين رأسيين أخرى وقائمة بخيارات الوصل.

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

ExtensionImages=
    هذا الإعداد مشابه لـ MountImages= من حيث إنه يوصل هرمية نظام ملفات من عقدة جهاز كتلي أو ملف عروة ارتجاعية، ولكن بدلاً من توفير مسار وجهة، سيُعد تراكب. يتوقع هذا الخيار قائمة مفصولة بمسافات بيضاء من تعريفات الوصل. يتكون كل تعريف من مسار مصدر، متبوعًا اختياريًا بنقطتين رأسيين وقائمة بخيارات الوصل.

    سيُعد 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.

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

    سيعَد نظام ملفات تراكبي (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.

هوية المستخدم/المجموعة

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

User=, Group=
    اضبط مستخدم أو مجموعة UNIX التي تُنفذ العمليات باسمها، على التوالي. يقبل اسم مستخدم أو مجموعة واحد، أو معرّفًا رقميًا كمعامل. بالنسبة لخدمات النظام (الخدمات التي يديرها مدير خدمات النظام، أي التي يديرها PID 1) ولخدمات المستخدم الخاصة بالمستخدم الجذر (الخدمات التي تديرها حالة root من systemd --user)، فإن القيمة المبدئية هي "root"، ولكن يمكن استخدام User= لتحديد مستخدم مختلف. بالنسبة لخدمات المستخدم لأي مستخدم آخر، لا يُسمح بتبديل هوية المستخدم، وبالتالي فإن الإعداد الصالح الوحيد هو نفس المستخدم الذي يعمل مدير خدمات المستخدم باسمه. إذا لم تُضبط أي مجموعة، تُستخدم المجموعة المبدئية للمستخدم. لا يؤثر هذا الإعداد على الأوامر المسبوقة بسطر أوامر يحمل علامة "+".

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

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

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

DynamicUser=
    يقبل معاملًا منطقيًا (boolean). إذا ضُبط، يُخصّص زوج من مستخدم ومجموعة UNIX ديناميكيًا وآليًا عند بدء الوحدة، ويُحرّر بمجرد إيقافها. لن يُضاف المستخدم والمجموعة إلى /etc/passwd أو /etc/group، ولكنهما يُداران بشكل عابر أثناء وقت التشغيل. توفر وحدة nss-systemd(8) الخاصة بـ glibc NSS تكاملًا لهؤلاء المستخدمين/المجموعات الديناميكيين في قواعد بيانات مستخدمي ومجموعات النظام. يمكن ضبط اسم المستخدم والمجموعة المراد استخدامهما عبر User= و Group= (انظر أعلاه). إذا لم تُستخدم هذه الخيارات وكان التخصيص الديناميكي للمستخدم/المجموعة مفعلاً لوحدة ما، فإن اسم المستخدم/المجموعة الديناميكي يُشتق ضمنيًا من اسم الوحدة. إذا كان اسم الوحدة بدون لاحقة النوع يصلح كاسم مستخدم صالح فيُستخدم مباشرة، وإلا فيُستخدم اسم يتضمن خلاصة (hash) له. إذا كان هناك مستخدم أو مجموعة مخصصة استاتيكيًا بالاسم المضبوط موجودة بالفعل، فتُستخدم ولا يُخصّص مستخدم/مجموعة ديناميكية. لاحظ أنه إذا حُدد User= وكانت المجموعة الساكنة بهذا الاسم موجودة، فمن المطلوب أن يكون المستخدم الساكن بهذا الاسم موجودًا بالفعل أيضًا. وبالمثل، إذا حُدد Group= وكان المستخدم الساكن بهذا الاسم موجودًا، فمن المطلوب أن تكون المجموعة الساكنة بهذا الاسم موجودة بالفعل. تُخصّص حسابات المستخدمين/المجموعات الديناميكية من نطاق UID/GID بقيمة 61184...65519. ويُوصى بتجنب هذا النطاق لمستخدمي النظام العاديين أو مستخدمي تسجيل الدخول. في أي نقطة زمنية، يُعين كل UID/GID من هذا النطاق إلى صفر أو مستخدم/مجموعة ديناميكية واحدة فقط قيد الاستخدام. ومع ذلك، تُعاد تدوير قيم UID/GID بعد إنهاء الوحدة. يجب توخي الحذر لضمان أن أي عمليات تعمل كجزء من وحدة فُعّل لها مستخدمون/مجموعات ديناميكيون لا تترك ملفات أو أدلة مملوكة لهؤلاء المستخدمين/المجموعات، حيث قد تحصل وحدة مختلفة على نفس الـ UID/GID المخصص لاحقًا، وبالتالي تكتسب القدرة على الوصول إلى هذه الملفات أو الأدلة. إذا فُعّل DynamicUser=، فإن RemoveIPC= يصبح ضمنيًا (ولا يمكن إيقافه). يضمن هذا أن عمر كائنات IPC والملفات المؤقتة التي أنشأتها العمليات المنفذة مرتبط بوقت تشغيل الخدمة، وبالتالي عمر المستخدم/المجموعة الديناميكية. نظرًا لأن /tmp/ و /var/tmp/ هما عادةً الأدلة الوحيدة القابلة للكتابة من الجميع على النظام، فما لم يُضبط PrivateTmp= يدويًا على "true"، فإن خيار "disconnected" سيكون ضمنيًا. يضمن هذا أن الوحدة التي تستخدم التخصيص الديناميكي للمستخدمين/المجموعات لا يمكنها ترك ملفات بعد إنهاء الوحدة. علاوة على ذلك، يُفعّل خيارا NoNewPrivileges= و RestrictSUIDSGID= ضمنيًا (ولا يمكن تعطيلهما)، لضمان أن العمليات المستدعاة لا يمكنها الاستفادة من أو إنشاء ملفات أو أدلة تحمل بتات SUID/SGID. بالإضافة إلى ذلك، يكون ProtectSystem=strict و ProtectHome=read-only ضمنيين، مما يمنع الخدمة من الكتابة في مواقع نظام ملفات عشوائية. وللسماح للخدمة بالكتابة في أدلة معينة، يجب إدراجها في القائمة المسموحة باستخدام ReadWritePaths=، ولكن يجب الحذر حتى لا يؤدي إعادة تدوير UID/GID إلى إنشاء مشكلات أمنية تتعلق بالملفات التي أنشأتها الخدمة. استخدم RuntimeDirectory= (انظر أدناه) لتعيين دليل تشغيل قابل للكتابة للخدمة، مملوك للمستخدم/المجموعة الديناميكية ويُزال آليًا عند إنهاء الوحدة. استخدم StateDirectory= و CacheDirectory= و LogsDirectory= لتعيين مجموعة من الأدلة القابلة للكتابة لأغراض محددة للخدمة بطريقة تحميها من الثغرات الأمنية الناتجة عن إعادة استخدام UID (انظر أدناه). إذا فُعّل هذا الخيار، فيجب توخي الحذر لضمان ألا تكتسب عمليات الوحدة حق الوصول إلى أدلة خارج هذه الأدلة المهيأة والمُدارة صراحةً. تحديدًا، لا تستخدم BindPaths= وكن حذرًا عند تمرير واصفات ملفات AF_UNIX لواصفات ملفات الأدلة، لأن هذا سيسمح للعمليات بإنشاء ملفات أو أدلة مملوكة للمستخدم/المجموعة الديناميكية لا تخضع لضمانات دورة حياة الخدمة والوصول إليها. لاحظ أن هذا الخيار غير متوافق حاليًا مع سياسات D-Bus، وبالتالي فإن الخدمة التي تستخدم هذا الخيار قد لا تُخصّص حاليًا اسم خدمة D-Bus (لاحظ أن هذا لا يؤثر على الاستدعاءات لخدمات D-Bus الأخرى). القيمة المبدئية هي الإيقاف.

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

SupplementaryGroups=
    يضبط مجموعات Unix الإضافية التي تُنفذ العمليات باسمها. يقبل هذا قائمة مفصولة بمسافات من أسماء المجموعات أو معرّفاتها. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُضبط جميع المجموعات المسرودة كمجموعات إضافية. عند تعيين سلسلة نصية فارغة، تُصفّر قائمة المجموعات الإضافية، ولن يكون لجميع التعيينات السابقة لهذا التعيين أي تأثير. على أي حال، لا يتجاوز هذا الخيار قائمة المجموعات الإضافية المهيأة في قاعدة بيانات مجموعات النظام للمستخدم، بل يمددها. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+".

SetLoginEnvironment=
    يقبل معاملًا منطقيًا يتحكم في ما إذا كان ستُضبط متغيرات البيئة $HOME و $LOGNAME و $SHELL. إذا لم يُضبط، فإن القيمة المبدئية تكون صائبة (true) إذا ضُبط User= أو DynamicUser= أو PAMName=، وتكون خاطئة (false) في غير ذلك. إذا ضُبط على true، فستُضبط المتغيرات دائمًا لخدمات النظام، أي حتى عند استخدام المستخدم المبدئي "root". إذا ضُبط على false، فإن المتغيرات المذكورة لا تُضبط من قِبل مدير الخدمات، بغض النظر عما إذا كان User= أو DynamicUser= أو PAMName= مستخدمًا أم لا. لا يكون لهذا الخيار عادة أي تأثير على خدمات مدير خدمات المستخدم، نظرًا لأن هذه المتغيرات في هذه الحالة تُورث عادة من البيئة الخاصة بمدير المستخدم نفسه على أي حال.

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

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

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

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

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

القدرات

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

CapabilityBoundingSet=
    يتحكم في القدرات (capabilities) التي يجب تضمينها في مجموعة حدود القدرات للعملية المنفذة. انظر capabilities(7) للتفاصيل. يقبل قائمة مفصولة بمسافات من أسماء القدرات، مثل CAP_SYS_ADMIN و CAP_DAC_OVERRIDE و CAP_SYS_PTRACE. القدرات المسرودة ستُضمّن في مجموعة الحدود، وتُزال جميع القدرات الأخرى. إذا كانت قائمة القدرات مسبوقة بعلامة "~", فستُضمّن جميع القدرات باستثناء المسرودة، ويُعكس تأثير التعيين. لاحظ أن هذا الخيار يؤثر أيضًا على القدرات المعنية في مجموعات القدرات الفعالة والمسموح بها والموروثة. إذا لم يُستخدم هذا الخيار، فلا تُعدّل مجموعة حدود القدرات عند تنفيذ العملية، وبالتالي لا تُفرض أي قيود على قدرات العملية. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج مجموعات الحدود بواسطة البوابة المنطقية OR، أو بواسطة AND إذا كانت السطور مسبوقة بعلامة "~" (انظر أدناه). إذا عُيّنت سلسلة نصية فارغة لهذا الخيار، فستُصفّر مجموعة الحدود إلى مجموعة قدرات فارغة، ولن يكون لجميع الإعدادات السابقة أي تأثير. وإذا ضُبط على "~" (بدون أي معامل إضافي)، فستُصفّر مجموعة الحدود إلى المجموعة الكاملة من القدرات المتاحة، مع إلغاء أي إعدادات سابقة أيضًا. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+".

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

AmbientCapabilities=
    يتحكم في القدرات التي يجب تضمينها في مجموعة القدرات المحيطة (ambient) للعملية المنفذة. يقبل قائمة مفصولة بمسافات من أسماء القدرات، مثل CAP_SYS_ADMIN و CAP_DAC_OVERRIDE و CAP_SYS_PTRACE. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج مجموعات القدرات المحيطة (انظر الأمثلة أعلاه في CapabilityBoundingSet=). إذا كانت قائمة القدرات مسبوقة بعلامة "~", فستُضمّن جميع القدرات باستثناء المسرودة، ويُعكس تأثير التعيين. إذا عُيّنت سلسلة نصية فارغة لهذا الخيار، فستُصفّر مجموعة القدرات المحيطة إلى مجموعة قدرات فارغة، ولن يكون لجميع الإعدادات السابقة أي تأثير. وإذا ضُبط على "~" (بدون أي معامل إضافي)، فستُصفّر مجموعة القدرات المحيطة إلى المجموعة الكاملة من القدرات المتاحة، مع إلغاء أي إعدادات سابقة أيضًا. لاحظ أن إضافة القدرات إلى مجموعة القدرات المحيطة يضيفها إلى مجموعة القدرات الموروثة للعملية.

    مجموعات القدرات المحيطة مفيدة إذا كنت تريد تنفيذ عملية كمستخدم غير ممتد الصلاحيات ولكنك لا تزال تريد منحه بعض القدرات. لاحظ أنه في هذه الحالة، يُضاف خيار keep-caps آليًا إلى SecureBits= للاحتفاظ بالقدرات أثناء تغيير المستخدم. لا يؤثر AmbientCapabilities= على الأوامر المسبوقة بعلامة "+".

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

الأمن

NoNewPrivileges=
    يقبل معاملًا منطقيًا. إذا كان صائبًا (true)، فإنه يضمن أن عملية الخدمة وجميع أبنائها لا يمكنهم أبدًا اكتساب امتيازات جديدة من خلال execve() (على سبيل المثال عبر بتات setuid أو setgid، أو قدرات نظام الملفات). هذه هي الطريقة الأبسط والأكثر فعالية لضمان عدم تمكن العملية وأبنائها من رفع الامتيازات مرة أخرى. القيمة المبدئية هي خاطئة (false). في حال كانت الخدمة ستعمل في مساحة أسماء وصل جديدة على أي حال وكان SELinux معطلاً، فإن جميع نظم الملفات تُوصل باستخدام علامة MS_NOSUID. انظر أيضًا علم عدم منح امتيازات جديدة[6].

    لاحظ أن هذا الإعداد له تأثير فقط على عمليات الوحدة نفسها (أو أي عمليات تفرعت عنها بشكل مباشر أو غير مباشر). وليس له أي تأثير على العمليات التي قد تُستدعى بناءً على طلب منها من خلال أدوات مثل at(1) أو crontab(1) أو systemd-run(1) أو خدمات IPC العشوائية.

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

SecureBits=
    يتحكم في البتات الآمنة (secure bits) المضبوطة للعملية المنفذة. يقبل مزيجًا مفصولاً بمسافات من الخيارات من القائمة التالية: keep-caps و keep-caps-locked و no-setuid-fixup و no-setuid-fixup-locked و noroot و noroot-locked. قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج البتات الآمنة بواسطة البوابة المنطقية OR. إذا عُيّنت سلسلة نصية فارغة لهذا الخيار، فستُصفّر البتات إلى 0. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+". انظر capabilities(7) للتفاصيل.

التحكم الإلزامي في الوصول

SELinuxContext=
    اضبط سياق أمان SELinux للعملية المنفذة. إذا ضُبط، فسيتجاوز هذا انتقال النطاق الآلي. ومع ذلك، لا تزال السياسة بحاجة إلى ترخيص هذا الانتقال. يُتجاهل هذا التوجيه إذا كان SELinux معطلاً. وإذا سُبق بعلامة "-"، فسيُتجاهل الفشل في ضبط سياق أمان SELinux، ولكن لا يزال من الممكن أن تفشل عملية execve() اللاحقة إذا كانت السياسة لا تسمح بالانتقال للسياق غير المتجاوَز. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+". انظر setexeccon(3) للتفاصيل.

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

AppArmorProfile=
    يقبل اسم تشكيلة كمعامل. ستنتقل العملية المنفذة بواسطة الوحدة إلى هذه التشكيلة عند بدئها. يجب أن تكون التشكيلات محملة بالفعل في النواة، وإلا فستفشل الوحدة. إذا سُبقت بعلامة "-"، فستُتجاهل جميع الأخطاء. ليس لهذا الإعداد أي تأثير إذا كان AppArmor غير مفعّل. لا يؤثر هذا الإعداد على الأوامر المسبوقة بعلامة "+".

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

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

SmackProcessLabel=
    يقبل وسم أمان SMACK64 كمعامل. ستبدأ العملية المنفذة بواسطة الوحدة تحت هذا الوسم وسيقرر SMACK ما إذا كان يُسمح للعملية بالعمل أم لا بناءً عليه. ستستمر العملية في العمل تحت الوسم المحدد هنا ما لم يكن للملف التنفيذي وسم SMACK64EXEC الخاص به، وفي هذه الحالة ستنتقل العملية للعمل تحت ذلك الوسم. عند عدم تحديده، يُستخدم الوسم الذي يعمل تحته نظام systemd. يُتجاهل هذا التوجيه إذا كان SMACK معطلاً.

    يمكن أن تُسبق القيمة بعلامة "-"، وفي هذه الحالة فستُتجاهل جميع الأخطاء. يمكن تحديد قيمة فارغة لإلغاء التعيينات السابقة. لا يؤثر هذا على الأوامر المسبوقة بعلامة "+".

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

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

خصائص العملية

LimitCPU=، LimitFSIZE=، LimitDATA=، LimitSTACK=، LimitCORE=، LimitRSS=، LimitNOFILE=، LimitAS=، LimitNPROC=، LimitMEMLOCK=، LimitLOCKS=، LimitSIGPENDING=، LimitMSGQUEUE=، LimitNICE=، LimitRTPRIO=، LimitRTTIME=
    اضبط الحدود المرنة (soft) والصارمة (hard) على الموارد المختلفة للعمليات المنفذة. انظر setrlimit(2) للتفاصيل حول مفهوم حد موارد العملية. يمكن تحديد حدود موارد العملية بصيغتين: إما كقيمة مفردة لضبط حد مرن وصارم محدد على نفس القيمة، أو كزوج مفصول بنقطتين رأسيّتين soft:hard لضبط كلا الحدين بشكل فردي (على سبيل المثال "LimitAS=4G:16G"). استخدم السلسلة النصية infinity لتهيئة عدم وجود حد على مورد معين. يمكن استخدام اللاحقات المضاعفة K و M و G و T و P و E (بالأساس 1024) لحدود الموارد المقاسة بالبايت (على سبيل المثال "LimitAS=16G"). بالنسبة للحدود التي تشير إلى قيم زمنية، يمكن استخدام وحدات الوقت المعتادة ms و s و min و h وما إلى ذلك (انظر systemd.time(7) للتفاصيل). لاحظ أنه إذا لم تُحدد وحدة زمنية لـ LimitCPU= فإن الوحدة المبدئية وهي الثواني تكون ضمنية، بينما لـ LimitRTTIME= فإن الوحدة المبدئية وهي الميكروثانية تكون ضمنية. أيضًا، لاحظ أن الحبيبية (granularity) الفعالة للحدود قد تؤثر على فرضها. على سبيل المثال، الحدود الزمنية المحددة لـ LimitCPU= ستُقرب لأعلى ضمنيًا إلى مضاعفات ثانية واحدة. بالنسبة لـ LimitNICE= يمكن تحديد القيمة بصيغتين: إذا كانت مسبوقة بعلامة "+" أو "-"، فستُفهم القيمة على أنها قيمة nice عادية لنظام Linux في النطاق -20...19. وإذا لم تكن مسبوقة على هذا النحو، فستُفهم القيمة كمعامل حد موارد خام في النطاق 0...40 (حيث يعادل 0 القيمة 1).

    لاحظ أن معظم حدود موارد العملية المهيأة بهذه الخيارات تكون لكل عملية (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 والوحدة المستخدمة
    التوجيه | ما يعادل ulimit | الوحدة | ملاحظات
    LimitCPU= | ulimit -t | ثوانٍ | -
    LimitFSIZE= | ulimit -f | بايتات | -
    LimitDATA= | ulimit -d | بايتات | لا تستخدمه. هذا يحدد نطاق العناوين المسموح به، وليس استخدام الذاكرة! القيمة المبدئية هي غير محدود ويجب عدم خفضها. للحد من استخدام الذاكرة، انظر MemoryMax= في systemd.resource-control(5).
    LimitSTACK= | ulimit -s | بايتات | -
    LimitCORE= | ulimit -c | بايتات | -
    LimitRSS= | ulimit -m | بايتات | لا تستخدمه. ليس له تأثير على Linux.
    LimitNOFILE= | ulimit -n | عدد واصفات الملفات | لا تستخدمه. كن حذرًا عند رفع الحد المرن فوق 1024، نظرًا لأن وظيفة select(2) لا يمكنها العمل مع واصفات ملفات أعلى من 1023 على Linux. في الوقت الحاضر، يؤول الحد الصارم مبدئيًا إلى 524288، وهي قيمة عالية جدًا مقارنة بالقيم المبدئية التاريخية. وعادةً ما ينبغي للتطبيقات زيادة حدها المرن إلى الحد الصارم من تلقاء نفسها، إذا كانت قادرة على العمل مع واصفات ملفات أعلى من 1023، أي لا تستخدم select(2). لاحظ أن واصفات الملفات تُحتسب في الوقت الحاضر مثل أي شكل آخر من أشكال الذاكرة، وبالتالي لا ينبغي أن تكون هناك أي حاجة لخفض الحد الصارم. استخدم MemoryMax= للتحكم في استخدام ذاكرة الخدمة الإجمالي، بما في ذلك ذاكرة واصفات الملفات.
    LimitAS= | ulimit -v | بايتات | لا تستخدمه. هذا يحدد نطاق العناوين المسموح به، وليس استخدام الذاكرة! القيمة المبدئية هي غير محدود ويجب عدم خفضها. للحد من استخدام الذاكرة، انظر MemoryMax= في systemd.resource-control(5).
    LimitNPROC= | ulimit -u | عدد العمليات | يُفرض هذا الحد بناءً على عدد العمليات التابعة للمستخدم. وعادةً ما يكون من الأفضل تتبع العمليات لكل خدمة، أي استخدام TasksMax=، انظر systemd.resource-control(5).
    LimitMEMLOCK= | ulimit -l | بايتات | -
    LimitLOCKS= | ulimit -x | عدد الأقفال | -
    LimitSIGPENDING= | ulimit -i | عدد الإشارات في الطابور | -
    LimitMSGQUEUE= | ulimit -q | بايتات | -
    LimitNICE= | ulimit -e | مستوى الأولوية | -
    LimitRTPRIO= | ulimit -r | أولوية الوقت الحقيقي | -
    LimitRTTIME= | ulimit -R | ميكروثانية | -

UMask=
    يتحكم في قناع إنشاء وضع الملف (umask). يقبل وضع وصول بالترميز الثماني. انظر umask(2) للتفاصيل. يؤول مبدئيًا إلى 0022 لوحدات النظام. بالنسبة لوحدات المستخدم، تُورث القيمة المبدئية من مدير الخدمات الخاص بكل مستخدم (والذي يُورث بدوره مبدئيًا من مدير خدمات النظام، وبالتالي يكون عادةً 0022 أيضًا — ما لم يتجاوزه موديل PAM). لتغيير قناع كل مستخدم لجميع خدمات المستخدم، ضع في اعتبارك ضبط إعداد UMask= لحالة خدمة النظام user@.service الخاصة بالمستعمل. يمكن أيضًا ضبط umask الخاص بكل مستخدم عبر حقل umask في سجل مستخدم JSON[7] الخاص بالمستعمل (بالنسبة للمستخدمين الذين تُدار حساباتهم بواسطة systemd-homed.service(8) يمكن التحكم في هذا الحقل عبر homectl --umask=). ويمكن أيضًا ضبطه عبر موديل PAM، مثل pam_umask(8).

CoredumpFilter=
    يتحكم في أنواع تخطيطات الذاكرة التي ستُحفظ إذا قامت العملية بتفريغ الذاكرة القلبية (core dump) (باستخدام ملف /proc/pid/coredump_filter). يقبل مزيجًا مفصولاً بمسافات من أسماء أنواع التخطيط أو أرقامها (مع الأساس المبدئي 16). أسماء أنواع التخطيط هي private-anonymous و shared-anonymous و private-file-backed و shared-file-backed و elf-headers و private-huge و shared-huge و private-dax و shared-dax، بالإضافة إلى القيم الخاصة all (جميع الأنواع) و default (القيمة المبدئية للنواة وهي "private-anonymous shared-anonymous elf-headers private-huge"). انظر core(5) لمعنى أنواع التخطيط. عند تحديدها عدة مرات، تُدمج جميع الأقنعة المحددة بواسطة بوابة OR المنطقية. عند عدم ضبطها، أو إذا عُيّنت قيمة فارغة، فلن تُغيّر القيمة الموروثة.

    مثال 8. إضافة صفحات DAX إلى مرشح التفريغ

        CoredumpFilter=default private-dax shared-dax

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

KeyringMode=
    يتحكم في كيفية إعداد حلقة مفاتيح جلسة النواة (kernel session keyring) للخدمة (انظر session-keyring(7) للتفاصيل حول حلقة مفاتيح الجلسة). يقبل أحد الخيارات inherit أو private أو shared. إذا ضُبط على inherit، فلن يُجرى أي إعداد خاص لحلقة المفاتيح، ويُطبّق السلوك المبدئي للنواة. وإذا استخدم private، فتُخصّص حلقة مفاتيح جلسة جديدة عند استدعاء عملية الخدمة، ولا تُربط بأي حلقة مفاتيح مستخدم. هذا هو الإعداد الموصى به لخدمات النظام، لأن هذا يضمن أن الخدمات المتعددة التي تعمل تحت نفس معرّف مستخدم النظام (خاصة المستخدم root) لا تشارك مواد المفاتيح الخاصة بها فيما بينها. وإذا استخدم shared، فتُخصّص حلقة مفاتيح جلسة جديدة كما في private، ولكن حلقة مفاتيح المستخدم للمستعمل المهيأ بـ User= تُربط بها، بحيث يمكن لعمليات الوحدة طلب المفاتيح المعينة للمستخدم. في هذا الوضع، قد تشارك وحدات متعددة تشغل عمليات تحت نفس معرّف المستخدم مواد المفاتيح. ما لم يُحدد inherit، فإن معرّف الاستدعاء الفريد للوحدة (انظر أدناه) يُضاف كمفتاح محمي باسم "invocation_id" إلى حلقة مفاتيح الجلسة التي أُنشئت حديثًا. يؤول مبدئيًا إلى private لخدمات مدير خدمات النظام وإلى inherit للوحدات التي ليست خدمات ولخدمات مدير خدمات المستخدم.

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

OOMScoreAdjust=
    يضبط قيمة التعديل لدرجة قاتل نقص الذاكرة (OOM killer score) لنواة Linux للعمليات المنفذة. يقبل عددًا صحيحًا بين -1000 (لتعطيل قتل العمليات التابعة لهذه الوحدة عند نقص الذاكرة) و1000 (لجعل قتل عمليات هذه الوحدة تحت ضغط الذاكرة محتملًا جدًا). انظر نظام ملفات /proc[8] للتفاصيل. إذا لم يُحدد، فإنه يؤول مبدئيًا إلى مستوى تعديل درجة OOM لمدير الخدمات نفسه، والذي يكون عادةً عند 0.

    استخدم إعداد OOMPolicy= لوحدات الخدمة لتهيئة كيفية تفاعل مدير الخدمات مع قاتل OOM للنواة أو إنهاء systemd-oomd لعملية تابعة للخدمة. انظر systemd.service(5) للتفاصيل.

TimerSlackNSec=
    يضبط فترة الارتخاء المؤقت (timer slack) بالنانوثانية للعمليات المنفذة. تتحكم فترة الارتخاء المؤقت في دقة عمليات الاستيقاظ الناتجة عن المؤقتات. انظر prctl(2) لمزيد من المعلومات. لاحظ أنه على عكس معظم تعريفات الفترة الزمنية الأخرى، يقبل هذا المعامل قيمة عددية صحيحة بالنانوثانية إذا لم تُحدد وحدة زمنية. تُفهم وحدات الوقت المعتادة أيضًا.

Personality=
    يتحكم في معمارية النواة التي يجب أن يبلغ عنها امر uname(2)، عندما تُستدعى بواسطة عمليات الوحدة. يقبل أحد معرفات المعمارية التالية arm64 أو arm64-be أو arm أو arm-be أو x86 أو x86-64 أو ppc أو ppc-le أو ppc64 أو ppc64-le أو s390 أو s390x. تعتمد معماريات الشخصية (personality architectures) المدعومة على المعمارية الأصلية للنواة. تدعم إصدارات 64-بت من معماريات النظام المختلفة عادةً نظيرتها المباشرة من معمارية الشخصية 32-بت، ولكن ليس غيرها. على سبيل المثال، تدعم أنظمة x86-64 شخصيات x86-64 و x86 ولكن ليس غيرها. ميزة الشخصية مفيدة عند تشغيل خدمات 32-بت على نظام مضيف 64-بت. إذا لم تُحدد، تُترك الشخصية دون تعديل وبالتالي تعكس شخصية نواة النظام المضيف. هذا الخيار ليس مفيدًا في المعماريات التي لم تتوفر لها سوى وحدة عرض كلمة أصلية واحدة فقط، مثل m68k (32-بت فقط) أو alpha (64-بت فقط).

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

IgnoreSIGPIPE=
    يقبل معاملًا منطقيًا. إذا كان صائبًا (true)، تُتجاهل إشارة SIGPIPE في العملية المنفذة. يؤول مبدئيًا إلى true لأن SIGPIPE تكون مفيدة عمومًا فقط في خطوط أنابيب الصدفة (shell pipelines).

جدولة

Nice=
    يضبط مستوى nice المبدئي (أولوية الجدولة) للعمليات المنفذة. يقبل عددًا صحيحًا بين -20 (أعلى أولوية) و19 (أقل أولوية). في حالة التنازع على الموارد، تعني القيم الأصغر إتاحة المزيد من الموارد لعمليات الوحدة، بينما تعني القيم الأكبر إتاحة موارد أقل. انظر setpriority(2) للتفاصيل.

CPUSchedulingPolicy=
    يضبط سياسة جدولة وحدة المعالجة المركزية (CPU) للعمليات المنفذة. يقبل أحد الخيارات other أو batch أو idle أو fifo أو rr أو ext. انظر sched_setscheduler(2) للتفاصيل.

CPUSchedulingPriority=
    يضبط أولوية جدولة وحدة المعالجة المركزية (CPU) للعمليات المنفذة. يعتمد نطاق الأولوية المتاح على سياسة جدولة CPU المحددة (انظر أعلاه). بالنسبة لسياسات جدولة الوقت الحقيقي، يمكن استخدام عدد صحيح بين 1 (أقل أولوية) و99 (أعلى أولوية). في حالة التنازع على موارد وحدة المعالجة المركزية، تعني القيم الأصغر إتاحة وقت أقل من المعالج للخدمة، وتعني القيم الأكبر إتاحة وقت أطول. انظر sched_setscheduler(2) للتفاصيل.

CPUSchedulingResetOnFork=
    يأخذ معاملًا منطقيًا (boolean). إذا كان صحيحًا (true)، فستُصفّر أولويات وسياسات جدولة المعالج المرفوعة عندما تستدعي العمليات المنفذة fork(2)، وبالتالي لا تتسرب إلى العمليات الابنة. انظر sched_setscheduler(2) للتفاصيل. القيمة المبدئية هي خطأ (false).

CPUAffinity=
    يتحكم في أُلفة المعالج (CPU affinity) للعمليات المنفذة. يأخذ قائمة بمؤشرات أو نطاقات المعالجات مفصولة إما بمسافات بيضاء أو فواصل. بدلاً من ذلك، يأخذ قيمة "numa" الخاصة وفي هذه الحالة يستنتج systemd آليًا نطاق المعالجات المسموح به بناءً على قيمة خيار NUMAMask=. تُحدد نطاقات المعالج بالمؤشرات الدنيا والعليا للمعالج مفصولة بشرطة. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أقنعة ألفة المعالج المحددة. إذا أُسندت سلسلة نصية فارغة، فسيُصفّر القناع، ولن يكون لأي تعيينات سابقة لهذا أي مفعول. انظر sched_setaffinity(2) للتفاصيل.

NUMAPolicy=
    يتحكم في سياسة ذاكرة NUMA للعمليات المنفذة. يأخذ نوع السياسة، وهي واحدة من: default و preferred و bind و interleave و local. يجب تحديد قائمة بعقد NUMA التي ينبغي أن ترتبط بالسياسة في NUMAMask=. لمزيد من التفاصيل حول كل سياسة، يرجى الاطلاع على set_mempolicy(2). للحصول على نظرة عامة شاملة لدعم NUMA في لينكس، انظر numa(7).

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

NUMAMask=
    يتحكم في قائمة عقد NUMA التي ستُطبق جنبًا إلى جنب مع سياسة NUMA المحددة. يأخذ قائمة بعقد NUMA وله نفس صيغة قائمة المعالجات لخيار CPUAffinity= أو القيمة الخاصة "all" التي ستشمل جميع عقد NUMA المتاحة في القناع. لاحظ أن قائمة عقد NUMA ليست مطلوبة للسياستين default و local، وبالنسبة لسياسة preferred فإننا نتوقع عقدة NUMA واحدة.

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

IOSchedulingClass=
    يضبط فئة جدولة الإدخال/الإخراج للعمليات المنفذة. يأخذ إحدى السلاسل النصية realtime أو best-effort أو idle. فئة الجدولة المبدئية للنواة هي best-effort بأولوية قدرها 4. إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فلن يكون لجميع التعيينات السابقة لكل من IOSchedulingClass= و IOSchedulingPriority= أي مفعول. انظر ioprio_set(2) للتفاصيل.

IOSchedulingPriority=
    يضبط أولوية جدولة الإدخال/الإخراج للعمليات المنفذة. يأخذ عددًا صحيحًا بين 0 (أعلى أولوية) و 7 (أقل أولوية). في حالة تزاحم الإدخال/الإخراج، تعني القيم الأصغر إتاحة المزيد من عرض نطاق الإدخال/الإخراج لعمليات الوحدة، وتعني القيم الأكبر عرض نطاق أقل. تعتمد الأولويات المتاحة على فئة جدولة الإدخال/الإخراج المحددة (انظر أعلاه). إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فلن يكون لجميع التعيينات السابقة لكل من IOSchedulingClass= و IOSchedulingPriority= أي مفعول. بالنسبة لفئة الجدولة المبدئية للنواة (best-effort)، فإن هذا يؤول مبدئيًا إلى 4. انظر ioprio_set(2) للتفاصيل.

العزل

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

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

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

ProtectSystem=
    يأخذ معاملًا منطقيًا أو القيم الخاصة "full" أو "strict". إذا كان صحيحًا (true)، فيُوصل /usr/ ودلائل محمل الإقلاع (/boot و /efi) بوضع القراءة فقط للعمليات التي تستدعيها هذه الوحدة. إذا ضُبط على "full"، فيُوصل الدليل /etc/ بوضع القراءة فقط أيضًا. وإذا ضُبط على "strict"، فيُوصل هيكل نظام الملفات بأكمله بوضع القراءة فقط، باستثناء أشجار نظام ملفات واجهة برمجة التطبيقات (API) الفرعية /dev/ و /proc/ و /sys/ (احمِ هذه الدلائل باستخدام PrivateDevices= و ProtectKernelTunables= و ProtectControlGroups=). يضمن هذا الإعداد حظر أي تعديل على نظام التشغيل المزود من المورد (واختياريًا تكوينه، والوصولات المحلية) على الخدمة. ويُوصى بتمكين هذا الإعداد لجميع الخدمات طويلة التشغيل، ما لم تكن مشاركة في تحديثات النظام أو تحتاج إلى تعديل نظام التشغيل بطرق أخرى. إذا استُخدم هذا الخيار، فيمكن استخدام ReadWritePaths= لاستبعاد دلائل معينة من جعلها للقراءة فقط. وبالمثل، فإن StateDirectory= و LogsDirectory= و ... وإعدادات الدلائل ذات الصلة (انظر أدناه) تستثني أيضًا دلائل معينة من تأثير ProtectSystem=. هذا الإعداد ضمني إذا ضُبط DynamicUser=. لا يمكن لهذا الإعداد ضمان الحماية في جميع الحالات. وعمومًا له نفس قيود ReadOnlyPaths=، انظر أدناه. القيمة المبدئية هي إيقاف (off).

    لاحظ أنه إذا ضُبط ProtectSystem= على "strict" ومُكّن PrivateTmp=، فإن /tmp/ و /var/tmp/ ستكون قابلة للكتابة.

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

ProtectHome=
    يأخذ معاملًا منطقيًا أو القيم الخاصة "read-only" أو "tmpfs". إذا كان صحيحًا، تُجعل الدلائل /home/ و /root و /run/user غير قابلة للوصول وفارغة للعمليات التي تستدعيها هذه الوحدة. وإذا ضُبط على "read-only"، تُجعل الدلائل الثلاثة للقراءة فقط بدلاً من ذلك. وإذا ضُبط على "tmpfs"، تُوصل أنظمة ملفات مؤقتة على الدلائل الثلاثة في وضع القراءة فقط. قيمة "tmpfs" مفيدة لإخفاء الدلائل المنزلية غير ذات الصلة بالعمليات التي تستدعيها الوحدة، مع السماح ببروز الدلائل الضرورية عند إدراجها في BindPaths= أو BindReadOnlyPaths=.

    ضبط هذا على "yes" يعادل في الغالب ضبط الدلائل الثلاثة في InaccessiblePaths=. وبالمثل، فإن "read-only" يعادل في الغالب ReadOnlyPaths=، و "tmpfs" يعادل في الغالب TemporaryFileSystem= مع ":ro".

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

    لاحظ أن هذا الإعداد لا يوفر أي حماية إذا وُضعت الدلائل المنزلية في موقع غير قياسي، أي خارج الهياكل المدرجة أعلاه.

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

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

RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=
    تأخذ هذه الخيارات قائمة بأسماء الدلائل مفصولة بمسافات بيضاء. يجب أن تكون أسماء الدلائل المحددة نسبية، ولا يجوز أن تتضمن "..". إذا ضُبطت، فعند بدء الوحدة، سيُنشأ دليل واحد أو أكثر بالأسماء المحددة (بما في ذلك الآباء) أسفل المواقع المحددة في الجدول التالي. وأيضًا، سيُعرّف متغير البيئة المقابل بالمسارات الكاملة للدلائل. إذا ضُبطت دلائل متعددة، فستُدمج المسارات في متغير البيئة بنقطتين رئيستين (":").

    إذا استُخدم DynamicUser=، وإذا كان إصدار النواة يدعم id-mapped mounts[9]، فستكون الدلائل المحددة مملوكة للمستخدم "nobody" في نطاق أسماء المضيف وستُربط بـ (وستكون مملوكة لـ) معرف المستخدم/المجموعة (UID/GID) الخاص بالخدمة في نطاق أسمائها الخاص. للتوافق مع الإصدارات السابقة، سيُحتفظ بالدلائل الحالية المنشأة بدون وصولات id-mapped دون مساس.

    جدول 2. إنشاء الدلائل آليًا ومتغيرات البيئة
    الدليل | أسفل مسار وحدات النظام | أسفل مسار وحدات المستخدم | متغير البيئة المعين
    RuntimeDirectory= | /run/ | $XDG_RUNTIME_DIR | $RUNTIME_DIRECTORY
    StateDirectory= | /var/lib/ | $XDG_STATE_HOME | $STATE_DIRECTORY
    CacheDirectory= | /var/cache/ | $XDG_CACHE_HOME | $CACHE_DIRECTORY
    LogsDirectory= | /var/log/ | $XDG_STATE_HOME/log/ | $LOGS_DIRECTORY
    ConfigurationDirectory= | /etc/ | $XDG_CONFIG_HOME | $CONFIGURATION_DIRECTORY

    في حالة 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.

RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=, ConfigurationDirectoryMode=
    يحدد وضع الوصول للدلائل المحددة في RuntimeDirectory= أو StateDirectory= أو CacheDirectory= أو LogsDirectory= أو ConfigurationDirectory=، على التوالي، كعدد ثماني. القيمة المبدئية هي 0755. انظر "Permissions" في path_resolution(7) لمناقشة معنى بتات الصلاحيات.

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

StateDirectoryQuota=, CacheDirectoryQuota=, LogsDirectoryQuota=
    يحدد حدود التخزين للدلائل المحددة في StateDirectory= أو CacheDirectory= أو LogsDirectory= على التوالي.

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

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

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

StateDirectoryAccounting=, CacheDirectoryAccounting=, LogsDirectoryAccounting=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا، يُعين معرف مشروع للدلائل المحددة في StateDirectory= أو CacheDirectory= أو LogsDirectory= على التوالي، والذي يُستخدم لتتبع استخدام القرص عند تشغيل حصص القرص (انظر repquota[12]). القيمة المبدئية هي خطأ (false).

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

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

RuntimeDirectoryPreserve=
    يأخذ معاملًا منطقيًا أو القيمة restart. إذا ضُبط على no (المبدئي)، تُزال الدلائل المحددة في RuntimeDirectory= دائمًا عند توقف الخدمة. وإذا ضُبط على restart، فيُحتفظ بالدلائل عند إعادة تشغيل الخدمة آليًا ويدويًا على حد سواء. هنا، تعني إعادة التشغيل الآلية العملية المحددة في Restart=، وتعني إعادة التشغيل اليدوية تلك التي يُطلقها الأمر systemctl restart foo.service. وإذا ضُبط على yes، فلا تُزال الدلائل عند إيقاف الخدمة. لاحظ أنه نظرًا لأن دليل التشغيل /run/ هو نقطة وصل لنظام "tmpfs"، فإن الدلائل المحددة في RuntimeDirectory= لخدمات النظام تُزال عند إعادة تشغيل النظام.

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

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

TimeoutCleanSec=
    يضبط مهلة لعملية التنظيف المطلوبة من خلال systemctl clean ...، انظر systemctl(1) للتفاصيل. يأخذ قيم الوقت المعتادة ويؤول مبدئيًا إلى اللانهاية (infinity)، أي لا تُطبق أي مهلة مبدئيًا. إذا ضُبطت مهلة، فستُجهض عملية التنظيف قسريًا عند الوصول إلى المهلة، مما قد يترك موارد على القرص.

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

ReadWritePaths=، ReadOnlyPaths=، InaccessiblePaths=، ExecPaths=، NoExecPaths=
    يُعد نطاق أسماء نظام ملفات جديد للعمليات المنفذة. يمكن استخدام هذه الخيارات للحد من وصول العملية إلى نظام الملفات. يأخذ كل إعداد قائمة مسارات مفصولة بمسافات نسبة إلى الدليل الجذر للمضيف (أي النظام الذي يشغل مدير الخدمة). لاحظ أنه إذا كانت المسارات تحتوي على روابط رمزية، فيُبت فيها نسبة إلى الدليل الجذر المعين باستخدام RootDirectory=/RootImage=.

    المسارات المدرجة في 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.

TemporaryFileSystem=
    يأخذ قائمة مفصولة بمسافات لنقاط وصل أنظمة الملفات المؤقتة (tmpfs). إذا ضُبط، يُعد نطاق أسماء نظام ملفات جديد للعمليات المنفذة، ويُوصل نظام ملفات مؤقت على كل نقطة وصل. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُوصل أنظمة ملفات مؤقتة على جميع نقاط الوصل المدرجة. إذا أُسندت السلسلة النصية الفارغة إلى هذا الخيار، فستُصفّر القائمة، ولن يكون لجميع التعيينات السابقة أي مفعول. يمكن اختياريًا إلحاق كل نقطة وصل بنقطتين رئيستين (":") وخيارات وصل مثل "size=10%" أو "ro". مبدئيًا، يُوصل كل نظام ملفات مؤقت بـ "nodev,strictatime,mode=0755". ويمكن تعطيل هذه الخيارات عن طريق تحديد خيارات الوصل المقابلة صراحةً، مثل "dev" أو "nostrictatime".

    هذا مفيد لإخفاء الملفات أو الدلائل غير ذات الصلة بالعمليات التي تستدعيها الوحدة، بينما لا يزال من الكن الوصول إلى الملفات أو الدلائل الضرورية من خلال الدمج مع BindPaths= أو BindReadOnlyPaths=:

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

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

    عندئذٍ لا يمكن للعمليات المستدعاة بواسطة الوحدة رؤية أي ملفات أو دلائل تحت /var/ باستثناء /var/lib/systemd أو محتوياته.

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

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

PrivateTmp=
    يأخذ معاملًا منطقيًا، أو "disconnected". إذا مُكّن، سيُعد نطاق أسماء نظام ملفات جديد للعمليات المنفذة، ولن تُشارك الدلائل /tmp/ و /var/tmp/ بداخله مع العمليات خارج نطاق الأسماء، بالإضافة إلى أن جميع الملفات المؤقتة المنشأة بواسطة الخدمة في هذه الدلائل تُزال بعد إيقاف الخدمة. بالنسبة لهذا الإعداد، تنطبق نفس القيود المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والاستدعاءات ذات الصلة، انظر أعلاه. هذا الإعداد مفيد لتأمين الوصول إلى الملفات المؤقتة للعملية، ولكنه يجعل المشاركة بين العمليات عبر /tmp/ أو /var/tmp/ مستحيلة. إذا مُكّن DynamicUser=، فإن "disconnected" يكون ضمنيًا. خلاف ذلك، يؤول مبدئيًا إلى خطأ (false).

    إذا كان "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
    إعدادات أخرى | tmpfs on /var/tmp/ | $TMPVAR | الاعتماديات الضمنية
    (لا شيء) | نعم | (غير معين) | WantsMountsFor=/var/
    RootDirectory=/RootImage= | نعم | (غير معين) | (لا شيء)
    DefaultDependency=no, RequiresMountsFor=/var/ | نعم | (غير معين) | (لا شيء)
    DefaultDependency=no, WantsMountsFor=/var/ | نعم | (غير معين) | (لا شيء)
    DefaultDependency=no | no | $TMPDIR=/tmp | (لا شيء)

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

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

PrivateDevices=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا، يُعد وصل /dev/ جديد للعمليات المنفذة ويضيف إليه فقط الأجهزة الوهمية لواجهة برمجة التطبيقات (API pseudo devices) مثل /dev/null و /dev/zero أو /dev/random (بالإضافة إلى نظام TTY الوهمي الفرعي)، ولكن لا يضيف أي أجهزة مادية مثل /dev/sda، وذاكرة النظام /dev/mem، ومنافذ النظام /dev/port وغيرها. هذا مفيد لإيقاف وصول العملية المنفذة إلى الأجهزة المادية. القيمة المبدئية هي خطأ (false).

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

PrivateNetwork=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا، يُعد نطاق أسماء شبكة جديد للعمليات المنفذة ويضبط جهاز شبكة الارتداد الملوى "lo" فقط بداخله. لن تتوفر أي أجهزة شبكة أخرى للعملية المنفذة. هذا مفيد لإيقاف وصول العملية المنفذة إلى الشبكة. القيمة المبدئية هي خطأ (false). ومن الممكن تشغيل وحدتين أو أكثر داخل نفس نطاق أسماء الشبكة الخاص باستخدام توجيه JoinsNamespaceOf=، انظر systemd.unit(5) للتفاصيل. لاحظ أن هذا الخيار سيفصل جميع عائلات المقابس عن المضيف، بما في ذلك AF_NETLINK و AF_UNIX. فعليًا، بالنسبة لـ AF_NETLINK، هذا يعني أن أحداث تكوين الجهاز المستلمة من systemd-udevd.service(8) لا تُسلم إلى عمليات الوحدة. وبالنسبة لـ AF_UNIX، فإن هذا يؤدي إلى جعل مقابس AF_UNIX في نطاق أسماء المقابس المجرد للمضيف غير متاحة لعمليات الوحدة (ومع ذلك، فإن تلك الموجودة في نظام الملفات ستظل قابلة للوصول).

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

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

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

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

UserNamespacePath=
    يأخذ مسار نظام ملفات مطلقًا يشير إلى ملف زائف لنطاق أسماء مستخدمي لينكس (أي ملفًا مثل /proc/$PID/ns/user أو وصلة ربط أو وصلة رمزية تؤدي إليه). عند ضبطه تُضاف العمليات المُستدعاة إلى نطاق أسماء المستخدمين المشار إليه بهذا المسار. يجب أن يشير المسار إلى ملف نطاق أسماء صالح في لحظة تفريع العمليات. وإذا اسْتُخدم هذا الخيار فلن يكون لـ PrivateUsers= أي أثر.

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

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

NetworkNamespacePath=
    يأخذ مسار نظام ملفات مطلقًا يشير إلى ملف زائف لنطاق أسماء شبكة لينكس (أي ملفًا مثل /proc/$PID/ns/net أو وصلة ربط أو وصلة رمزية تؤدي إليه). عند ضبطه تُضاف العمليات المُستدعاة إلى نطاق أسماء الشبكة المشار إليه بهذا المسار. يجب أن يشير المسار إلى ملف نطاق أسماء صالح في لحظة تفريع العمليات. وإذا اسْتُخدم هذا الخيار فلن يكون لـ PrivateNetwork= أي أثر. وإذا اسْتُخدم هذا الخيار مع JoinsNamespaceOf= فإنه يؤثر فقط إذا بُدئت هذه الوحدة قبل أي من الوحدات المدرجة التي ضُبط فيها PrivateNetwork= أو NetworkNamespacePath=، وإلا فستُعاد استخدام نطاق أسماء الشبكة لتلك الوحدات.

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

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

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

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

PrivateIPC=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، يُهيئ نطاق أسماء IPC جديد للعمليات المُنفذة. لكل نطاق أسماء IPC مجموعته الخاصة من معرفات System V IPC ونظام ملفات صف رسائل POSIX الخاص به. هذا مفيد لتفادي تضارب أسماء معرفات IPC. القيمة المبدئية هي خطأ (false). يمكن تشغيل وحدتين أو أكثر داخل نطاق أسماء IPC الخاص نفسه باستخدام توجيه JoinsNamespaceOf=، انظر systemd.unit(5) للتفاصيل.

    لاحظ أن نطاقات أسماء 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.

IPCNamespacePath=
    يأخذ مسار نظام ملفات مطلقًا يشير إلى ملف زائف لنطاق أسماء IPC لينكس (أي ملفًا مثل /proc/$PID/ns/ipc أو وصلة ربط أو وصلة رمزية تؤدي إليه). عند ضبطه تُضاف العمليات المُستدعاة إلى نطاق أسماء الشبكة المشار إليه بهذا المسار. يجب أن يشير المسار إلى ملف نطاق أسماء صالح في لحظة تفريع العمليات. وإذا اسْتُخدم هذا الخيار فلن يكون لـ PrivateIPC= أي أثر. وإذا اسْتُخدم هذا الخيار مع JoinsNamespaceOf= فإنه يؤثر فقط إذا بُدئت هذه الوحدة قبل أي من الوحدات المدرجة التي ضُبط فيها PrivateIPC= أو IPCNamespacePath=، وإلا فستُعاد استخدام نطاق أسماء الشبكة لتلك الوحدات.

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

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

MemoryKSM=
    يأخذ معاملًا منطقيًا. عند ضبطه، يُفعل ميزة دمج صفحات النواة المتطابقة (KSM) للعمليات. تعد KSM ميزة لتقليل التكرار وتوفير الذاكرة. حيث يمكن استبدال صفحات الذاكرة المجهولة ذات المحتوى المتطابق بصفحة واحدة محمية من الكتابة. ينبغي تفعيل هذه الميزة فقط للوظائف التي تتشارك في نطاق الأمان نفسه. للتفاصيل، انظر Kernel Samepage Merging[13] في توثيق النواة.

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

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

MemoryTHP=
    الصفحات الضخمة الشفافة (THPs) هي ميزة في نواة لينكس تدير الذاكرة باستخدام صفحات أكبر (2 ميجابايت على معمارية x86، مقارنة بالحجم المبدئي وهو 4 كيلوبايت). الهدف الرئيس هو تحسين كفاءة إدارة الذاكرة وأداء النظام، لا سيما للتطبيقات الكثيفة الاستهلاك للذاكرة. ومع ذلك، يمكن أن تتسبب في عيوب في بعض السيناريوهات، مثل تراجع الذاكرة وقفزات في زمن الاستجابة. تُحكم سياسة THP للنظام بأكمله عبر /sys/kernel/mm/transparent_hugepage/enabled. ومع ذلك، يمكن تجاوزها لأعباء العمل الفردية عبر prctl(2). يمكن استخدام MemoryTHP= لتعطيل THPs في وقت استدعاء العملية لإيقاف تقديم THPs لأعباء العمل التي تفوق عيوبُها مزاياها. عندما يُضبط MemoryTHP= على "inherit" أو لا يُضبط على الإطلاق، يرث systemd إعدادات THP من العملية التي تبدأه ولا يُجرى أي استدعاء لـ prctl(2) PR_SET_THP_DISABLE. وعند ضبطه على "disable"، يعطل MemoryTHP= صفحات THPs تمامًا للعملية، بغض النظر عن عناصر التحكم العامة في THP. وعند ضبطه على "madvise"، يعطل MemoryTHP= صفحات THPs للعملية باستثناء الحالات التي تُطلب فيها تحديدًا عبر madvise(2) بواسطة العملية باستخدام MADV_HUGEPAGE أو MADV_COLLAPSE. وعند ضبطه على "system"، يعيد MemoryTHP= ضبط سياسة THP إلى السياسة الشاملة للنظام. يمكن استخدام هذا عندما تكون العملية التي تبدأ systemd قد عطلت THPs بالفعل عبر PR_SET_THP_DISABLE، ونريد استعادة ضبط THP المبدئي للنظام في وقت استدعاء العملية. للتفاصيل، انظر Transparent Hugepage Support[14] في توثيق النواة.

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

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

PrivatePIDs=
    يأخذ معاملًا منطقيًا. القيمة المبدئية هي خطأ (false). إذا فُعِّل، يُهيئ نطاق أسماء PID جديد للعمليات المُنفذة. تصبح كل عملية مُنفذة الآن هي PID 1 - عملية بدء التشغيل (init) - في نطاق الأسماء الجديد. ويُوصَل /proc/ بحيث لا تظهر سوى العمليات الموجودة في نطاق أسماء PID. إذا ضُبط PrivatePIDs=، فإن هذا يتضمن ضُمنًا MountAPIVFS=yes.

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

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

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

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

PrivateUsers=
    يأخذ معاملًا منطقيًا أو أحد القيم التالية: "self" أو "identity" أو "full" أو "managed". القيمة المبدئية هي خطأ (false). إذا فُعِّل، يُهيئ نطاق أسماء مستخدمين جديد للعمليات المُنفذة ويضبط تخطيطًا للمستخدمين والمجموعات. إذا ضُبط على قيمة صحيحة أو "self"، يُضبط تخطيط مستخدمين ومجموعات أدنى يخطط مستخدم ومجموعة "root" بالإضافة إلى مستخدم ومجموعة الوحدة نفسها إلى أنفسهم، ويخطط كل شيء آخر إلى مستخدم ومجموعة "nobody". هذا مفيد لفصل قواعد بيانات المستخدمين والمجموعات التي تستخدمها الوحدة بأمان عن بقية النظام، وبالتالي إنشاء بيئة عزل (sandbox) فعالة. ستبقى جميع الملفات والأدلة والعمليات وكائنات IPC والموارد الأخرى المملوكة لمستخدمين/مجموعات لا تساوي "root" أو مستخدم/مجموعة الوحدة مرئية من داخل الوحدة ولكنها ستظهر كما لو كانت مملوكة للمستخدم والمجموعة "nobody".

    إذا كان المعامل هو "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.

ProtectHostname=
    يأخذ معاملًا منطقيًا أو القيمة "private". إذا فُعِّل، يُهيئ نطاق أسماء UTS جديد للعمليات المُنفذة. وإذا فُعِّل، يمكن اختياريًا تحديد اسم مضيف بعد نقطتين رأسيتين (مثل "yes:foo" أو "private:host.example.com")، ويُضبط اسم المضيف في نطاق أسماء UTS الجديد للوحدة. إذا ضُبط على قيمة صحيحة، يُمنع تغيير اسم المضيف أو اسم النطاق عبر نداءات النظام sethostname() و setdomainname(). وإذا ضُبط على "private"، يُسمح بتغيير اسم المضيف أو اسم النطاق ولكنه يؤثر فقط على نطاق أسماء UTS الخاص بالوحدة. القيمة المبدئية هي الإيقاف (off).

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

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

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

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

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

ProtectClock=
    يأخذ معاملًا منطقيًا. إذا ضُبط، ستُرفض عمليات الكتابة في ساعة العتاد أو ساعة النظام. القيمة المبدئية هي الإيقاف (off). يؤدي تفعيل هذا الخيار إلى إزالة CAP_SYS_TIME و CAP_WAKE_ALARM من مجموعة تحديد القدرات لهذه الوحدة، ويُثبّت مرشح نداءات النظام لحظر النداءات التي يمكنها ضبط الساعة، ويتضمن ضُمنًا DeviceAllow=char-rtc r. لاحظ أن نداءات النظام تُحظر تمامًا، ولا يأخذ المرشح في الحسبان أن بعض النداءات يمكن استخدامها لقراءة حالة الساعة مع بعض مجموعات المعاملات. وعمليًا، تصبح الملفات /dev/rtc0 و /dev/rtc1 وغيرها للقراءة فقط بالنسبة للخدمة. انظر systemd.resource-control(5) للتفاصيل حول DeviceAllow=.

    يُوصى بتشغيل هذا لمعظم الخدمات التي لا تحتاج إلى تعديل الساعة أو التحقق من حالتها.

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

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

ProtectKernelTunables=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، فإن متغيرات النواة التي يمكن الوصول إليها عبر /proc/sys/ و /sys/ و /proc/sysrq-trigger و /proc/latency_stats و /proc/acpi و /proc/timer_stats و /proc/fs و /proc/irq ستصبح للقراءة فقط، وسيتعذر الوصول إلى /proc/kallsyms و /proc/kcore لجميع عمليات الوحدة. عادةً، ينبغي تهيئة متغيرات النواة القابلة للضبط في وقت بدء التشغيل فقط، على سبيل المثال باستخدام آلية sysctl.d(5). وقليل من الخدمات تحتاج إلى الكتابة فيها في وقت التشغيل؛ لذا يُوصى بتشغيل هذا الخيار لمعظم الخدمات. ينطبق على هذا الضبط القيود نفسها المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والنداءات ذات الصلة، انظر أعلاه. القيمة المبدئية هي الإيقاف (off). لاحظ أن هذا الخيار لا يمنع التغييرات غير المباشرة لمتغيرات النواة القابلة للضبط المتأثرة بنداءات IPC لعمليات أخرى. ومع ذلك، يمكن استخدام InaccessiblePaths= لجعل كائنات نظام ملفات IPC ذات الصلة غير قابلة للوصول. إذا ضُبط ProtectKernelTunables=، يتضمن هذا ضُمنًا MountAPIVFS=yes.

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

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

ProtectKernelModules=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، سيرفض تحميل الوحدات النمطية الصريح. يتيح هذا إيقاف عمليات تحميل وتفريغ الوحدات النمطية في النوايا المجزأة. يُوصى بتشغيل هذا لمعظم الخدمات التي لا تحتاج إلى أنظمة ملفات خاصة أو وحدات نمطية إضافية للنواة لكي تعمل. القيمة المبدئية هي الإيقاف (off). يؤدي تفعيل هذا الخيار إلى إزالة CAP_SYS_MODULE من مجموعة تحديد القدرات للوحدة، ويُثبّت مرشح نداءات النظام لحظر نداءات نظام الوحدات النمطية، كما يجعل الدليل /usr/lib/modules غير قابل للوصول. ينطبق على هذا الضبط القيود نفسها المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والنداءات ذات الصلة، انظر أعلاه. لاحظ أن التحميل التلقائي المحدود للوحدات النمطية بسبب تهيئة المستخدم أو جداول تخطيط النواة قد يحدث كأثر جانبي لعمليات المستخدم المطلوبة، سواء كانت ممتلكة للامتيازات أم لا. لتعطيل ميزة التحميل التلقائي للوحدات النمطية، يرجى مراجعة آلية kernel.modules_disabled في sysctl.d(5) وتوثيق /proc/sys/kernel/modules_disabled.

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

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

ProtectKernelLogs=
    يأخذ معاملًا منطقيًا. إذا كان صحيحًا (true)، سيُرفض الوصول إلى المخزن المؤقت الدائري لسجلات النواة. يُوصى بتشغيل هذا الخيار لمعظم الخدمات التي لا تحتاج إلى القراءة من المخزن المؤقت الدائري لسجلات النواة أو الكتابة فيه. يؤدي تفعيل هذا الخيار إلى إزالة CAP_SYSLOG من مجموعة تحديد القدرات لهذه الوحدة، ويُثبّت مرشح نداءات النظام لحظر نداء النظام syslog(2) (لا ينبغي الخلط بينه وبين واجهة برمجة تطبيقات libc المسماة syslog(3) للتسجيل في مساحة المستخدم). تعرض النواة مخزن سجلاتها المؤقت لمساحة المستخدم عبر /dev/kmsg و /proc/kmsg. إذا فُعِّل، تصبح هذه الملفات غير قابلة للوصول لجميع العمليات في الوحدة.

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

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

ProtectControlGroups=
    يأخذ معاملًا منطقيًا أو القيم الخاصة "private" أو "strict". إذا كان صحيحًا (true)، فإن تسلسلات مجموعات التحكم في لينكس (cgroups(7)) التي يمكن الوصول إليها عبر /sys/fs/cgroup/ ستصبح للقراءة فقط لجميع عمليات الوحدة. وإذا ضُبط على "private"، فستعمل الوحدة في نطاق أسماء cgroup مع وصلة مستقلة قابلة للكتابة لـ /sys/fs/cgroup/. وإذا ضُبط على "strict"، فستعمل الوحدة في نطاق أسماء cgroup مع وصلة مستقلة للقراءة فقط لـ /sys/fs/cgroup/. القيمة المبدئية هي الإيقاف (off). إذا ضُبط ProtectControlGroups=، يتضمن هذا ضُمنًا MountAPIVFS=yes. لاحظ أن القيمة "private" تُخفّض إلى خطأ (false) والقيمة "strict" تُخفّض إلى صحيح (true) ما لم يكن النظام يستخدم تسلسل مجموعات التحكم الموحد وكانت النواة تدعم نطاقات أسماء cgroup.

    باستثناء مديري الحاويات، لا ينبغي لأي خدمات أن تتطلب صلاحية الكتابة في تسلسلات مجموعات التحكم؛ لذا يُوصى بضبط ProtectControlGroups= على صحيح (true) أو "strict" لمعظم الخدمات. ينطبق على هذا الضبط القيود نفسها المتعلقة بانتشار الوصل والامتيازات كما في ReadOnlyPaths= والضبط ذي الصلة، انظر أعلاه.

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

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

RestrictAddressFamilies=
    يقيد مجموعة عائلات عناوين المقابس التي يمكن لعمليات هذه الوحدة الوصول إليها. يأخذ القيمة "none"، أو قائمة مفصولة بمسافات لأسماء عائلات العناوين للسماح بها (قائمة مسموحات)، مثل AF_UNIX أو AF_INET أو AF_INET6، انظر address_families(7) لجميع الخيارات الممكنة. عند تحديد "none"، ستُرفض جميع عائلات العناوين. وعند بدئها بالعلامة "~"، ستُطبق عائلات العناوين المدرجة كقائمة ممنوعات، وإلا فستُطبق كقائمة مسموحات.

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

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

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

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

        RestrictFileSystems=ext4 tmpfs
        RestrictFileSystems=ext2 ext4

    عندئذٍ يُسمح بالوصول إلى ext4 و tmpfs و ext2 ويُرفض الوصول إلى أنظمة الملفات الأخرى.

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

        RestrictFileSystems=ext4 tmpfs
        RestrictFileSystems=~ext4

    عندئذٍ يُسمح فقط بالوصول إلى tmpfs.

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

        RestrictFileSystems=~ext4 tmpfs
        RestrictFileSystems=ext4

    عندئذٍ يُحظر فقط الوصول إلى tmpfs.

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

    جدول 4. مجموعات أنظمة الملفات المعرفة مسبقًا حاليًا
    المجموعة | الوصف
    @basic-api | واجهة برمجة تطبيقات نظام الملفات الأساسية.
    @auxiliary-api | واجهة برمجة تطبيقات نظام الملفات المساعدة.
    @common-block | أنظمة ملفات الأجهزة الكتلية الشائعة.
    @historical-block | أنظمة ملفات الأجهزة الكتلية القديمة.
    @network | أنظمة ملفات الشبكة المعروفة جزيلاً.
    @privileged-api | واجهة برمجة تطبيقات نظام الملفات ذات الامتيازات.
    @temporary | أنظمة الملفات المؤقتة: tmpfs, ramfs.
    @known | جميع أنظمة الملفات المعروفة والمعرفة من قبل النواة. هذه القائمة معرفة استاتيكيًا في systemd بناءً على نسخة النواة التي كانت متوفرة عند إصدار نسخة systemd هذه. ستصبح قديمة تدريجيًا مع تحديث النواة.

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

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

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

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

RestrictNamespaces=
    يقيد الوصول إلى وظائف نطاق أسماء لينكس لعمليات هذه الوحدة. للتفاصيل حول نطاقات أسماء لينكس، انظر namespaces(7). يأخذ إما معاملًا منطقيًا، أو قائمة مفصولة بمسافات لمعرفات نوع نطاق الأسماء. إذا كان خطأ (false) وهو المبدئي، فلا تُفرض أي قيود على إنشاء نطاقات الأسماء والتبديل بينها. وإذا كان صحيحًا (true)، يُحظر الوصول إلى أي نوع من نطاقات الأسماء. بخلاف ذلك، يجب تحديد قائمة مفصولة بمسافات لمعرفات أنواع نطاقات الأسماء، تتكون من أي مزيج من: cgroup و ipc و net و mnt و pid و user و uts و time. أي نوع نطاق أسماء مدرج يصبح متاحًا لعمليات الوحدة، ويُحظر الوصول إلى أنواع نطاقات الأسماء غير المدرجة (قائمة مسموحات). وعبر بدء القائمة بعلامة مَدة واحدة ("~") يمكن عكس التأثير: تصبح أنواع نطاقات الأسماء المدرجة فقط غير قابلة للوصول، ويُسمح بجميع الأنواع غير المدرجة (قائمة ممنوعات). إذا عُينت سلسلة نصية فارغة، تُطبق قيود نطاق الأسماء المبدئية، وهو ما يعادل خطأ (false). قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أنواع نطاقات الأسماء بواسطة عامل المنطق OR، أو بواسطة AND إذا كانت السطور مسبوقة بـ "~" (انظر الأمثلة أدناه). داخليًا، يحد هذا الضبط من الوصول إلى نداءات النظام unshare(2) و clone(2) و setns(2)، آخذًا معاملات الأعلام المحددة في الحسبان. لاحظ أنه — إذا اسْتُخدم هذا الخيار — فبالإضافة إلى تقييد إنشاء وتبديل أنواع نطاقات الأسماء المحددة (أو جميعها، إذا كان صحيحًا) يُحظر الوصول إلى نداء النظام setns() مع معامل أعلام صفري. هذا الضبط مدعوم فقط على معماريات x86 و x86-64 و mips و mips-le و mips64 و mips64-le و mips64-n32 و mips64-le-n32 و ppc64 و ppc64-le و s390 و s390x، ولا يفرض أي قيود على المعماريات الأخرى.

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

        RestrictNamespaces=cgroup ipc
        RestrictNamespaces=cgroup net

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

        RestrictNamespaces=cgroup ipc
        RestrictNamespaces=~cgroup net

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

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

DelegateNamespaces=
    يفوض ملكية أنواع نطاقات الأسماء المحددة إلى نطاق أسماء مستخدمي عمليات هذه الوحدة. للتفاصيل حول نطاقات أسماء لينكس، انظر namespaces(7). يأخذ إما معاملًا منطقيًا، أو قائمة مفصولة بمسافات لمعرفات نوع نطاق الأسماء. إذا كان خطأ (false) وهو المبدئي، فلن يكون لنطاق أسماء مستخدمي عمليات الوحدة ملكية على أي نطاقات أسماء تُنشأ أثناء إعداد بيئة الوحدة المعزولة. وإذا كان صحيحًا (true)، فإن ملكية جميع أنواع نطاقات الأسماء (باستثناء نطاقات أسماء المستخدمين، حيث لا ينطبق المفهوم) المنشأة أثناء إعداد بيئة الوحدة المعزولة تُفوَّض إلى نطاق أسماء مستخدمي عمليات الوحدة. بخلاف ذلك، يجب تحديد قائمة مفصولة بمسافات لمعرفات أنواع نطاقات الأسماء، تتكون من أي مزيج من: cgroup و ipc و net و mnt و pid و uts. وستكون جميع نطاقات الأسماء من الأنواع المدرجة مملوكة لنطاق أسماء مستخدمي عمليات الوحدة إذا أُنْشئت أثناء إعداد بيئة الوحدة المعزولة (قائمة مسموحات). وعبر بدء القائمة بعلامة مَدة واحدة ("~") يمكن عكس التأثير: ستكون جميع نطاقات الأسماء من الأنواع غير المدرجة والمنشأة أثناء إعداد بيئة الوحدة المعزولة مملوكة لنقاط أسماء مستخدمي عمليات الوحدة (قائمة ممنوعات). إذا عُينت سلسلة نصية فارغة، تُطبق ملكية نطاق الأسماء المبدئية، وهو ما يعادل خطأ (false). قد يظهر هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أنواع نطاقات الأسماء بواسطة عامل المنطق OR، أو بواسطة AND إذا كانت السطور مسبوقة بـ "~" (انظر الأمثلة أدناه). داخليًا، يتحكم هذا الضبط في الترتيب الذي يُلغى به تشارك نطاقات الأسماء بواسطة systemd. أنواع نطاقات الأسماء التي ينبغي أن تكون مملوكة لنطاق أسماء مستخدمي عمليات الوحدة سيُلغى تشاركها بعد إلغاء تشارك نطاق أسماء المستخدمين. داخليًا، يتحكم هذا الضبط في ترتيب إلغاء تشارك نطاقات الأسماء. نطاقات الأسماء المفوضة سيُلغى تشاركها بعد إلغاء تشارك نطاق أسماء المستخدمين. ونطاقات الأسماء الأخرى سيُلغى تشاركها قبل إلغاء تشارك نطاق أسماء المستخدمين.

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

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

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

PrivateBPF=
    يأخذ معاملًا منطقيًا. إذا ضُبط، تُوصل نسخة مستقلة من نظام ملفات BPF على /sys/fs/bpf/، مما يخفي بفعالية نظام ملفات bpffs الخاص بالمضيف والذي يحتوي على معلومات حول البرامج والخرائط المحملة. خلاف ذلك، إذا ضُبط ProtectKernelTunables=، تُورث النسخة من المضيف ولكن تُوصل كقراءة فقط. القيمة المبدئية هي خطأ (false).

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

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

BPFDelegateCommands=
    يقبل قائمة بأوامر BPF للسماح بها أو "any" للسماح بكل شيء. القيمة المبدئية هي لا شيء (none). القيم المقبولة هي: BPFMapCreate و BPFMapLookupElem و BPFMapUpdateElem و BPFMapDeleteElem و BPFMapGetNextKey و BPFProgLoad و BPFObjPin و BPFObjGet و BPFProgAttach و BPFProgDetach و BPFProgTestRun و BPFProgGetNextId و BPFMapGetNextId و BPFProgGetFdById و BPFMapGetFdById و BPFObjGetInfoByFd و BPFProgQuery و BPFRawTracepointOpen و BPFBtfLoad و BPFBtfGetFdById و BPFTaskFdQuery و BPFMapLookupAndDeleteElem و BPFMapFreeze و BPFBtfGetNextId و BPFMapLookupBatch و BPFMapLookupAndDeleteBatch و BPFMapUpdateBatch و BPFMapDeleteBatch و BPFLinkCreate و BPFLinkUpdate و BPFLinkGetFdById و BPFLinkGetNextId و BPFEnableStats و BPFIterCreate و BPFLinkDetach و BPFProgBindMap و BPFTokenCreate و BPFProgStreamReadByFd و BPFProgAssocStructOps. سيقوم هذا بضبط خيار وصل bpffs المسمى delegate_cmds.

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

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

BPFDelegateMaps=
    يقبل قائمة بخرائط BPF للسماح بها أو "any" للسماح بكل شيء. القيمة المبدئية هي لا شيء (none). القيم المقبولة هي: BPFMapTypeUnspec و BPFMapTypeHash و BPFMapTypeArray و BPFMapTypeProgArray و BPFMapTypePerfEventArray و BPFMapTypePercpuHash و BPFMapTypePercpuArray و BPFMapTypeStackTrace و BPFMapTypeCgroupArray و BPFMapTypeLruHash و BPFMapTypeLruPercpuHash و BPFMapTypeLpmTrie و BPFMapTypeArrayOfMaps و BPFMapTypeHashOfMaps و BPFMapTypeDevmap و BPFMapTypeSockmap و BPFMapTypeCpumap و BPFMapTypeXskmap و BPFMapTypeSockhash و BPFMapTypeCgroupStorageDeprecated و BPFMapTypeReuseportSockarray و BPFMapTypePercpuCgroupStorageDeprecated و BPFMapTypeQueue و BPFMapTypeStack و BPFMapTypeSkStorage و BPFMapTypeDevmapHash و BPFMapTypeStructOps و BPFMapTypeRingbuf و BPFMapTypeInodeStorage و BPFMapTypeTaskStorage و BPFMapTypeBloomFilter و BPFMapTypeUserRingbuf و BPFMapTypeCgrpStorage و BPFMapTypeArena و BPFMapTypeInsnArray. سيقوم هذا بضبط خيار وصل bpffs المسمى delegate_maps.

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

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

BPFDelegatePrograms=
    يقبل قائمة ببرامج BPF للسماح بها أو "any" للسماح بكل شيء. القيمة المبدئية هي لا شيء (none). القيم المقبولة هي: BPFProgTypeUnspec و BPFProgTypeSocketFilter و BPFProgTypeKprobe و BPFProgTypeSchedCls و BPFProgTypeSchedAct و BPFProgTypeTracepoint و BPFProgTypeXdp و BPFProgTypePerfEvent و BPFProgTypeCgroupSkb و BPFProgTypeCgroupSock و BPFProgTypeLwtIn و BPFProgTypeLwtOut و BPFProgTypeLwtXmit و BPFProgTypeSockOps و BPFProgTypeSkSkb و BPFProgTypeCgroupDevice و BPFProgTypeSkMsg و BPFProgTypeRawTracepoint و BPFProgTypeCgroupSockAddr و BPFProgTypeLwtSeg6local و BPFProgTypeLircMode2 و BPFProgTypeSkReuseport و BPFProgTypeFlowDissector و BPFProgTypeCgroupSysctl و BPFProgTypeRawTracepointWritable و BPFProgTypeCgroupSockopt و BPFProgTypeTracing و BPFProgTypeStructOps و BPFProgTypeExt و BPFProgTypeLsm و BPFProgTypeSkLookup و BPFProgTypeNetfilter. سيقوم هذا بضبط خيار وصل bpffs المسمى delegate_progs.

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

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

BPFDelegateAttachments=
    يقبل قائمة بنقاط إرفاق BPF للسماح بها أو "any" للسماح بكل شيء. القيمة المبدئية هي لا شيء (none). القيم المقبولة هي: BPFCgroupInetIngress و BPFCgroupInetEgress و BPFCgroupInetSockCreate و BPFCgroupSockOps و BPFSkSkbStreamParser و BPFSkSkbStreamVerdict و BPFCgroupDevice و BPFSkMsgVerdict و BPFCgroupInet4Bind و BPFCgroupInet6Bind و BPFCgroupInet4Connect و BPFCgroupInet6Connect و BPFCgroupInet4PostBind و BPFCgroupInet6PostBind و BPFCgroupUdp4Sendmsg و BPFCgroupUdp6Sendmsg و BPFLircMode2 و BPFFlowDissector و BPFCgroupSysctl و BPFCgroupUdp4Recvmsg و BPFCgroupUdp6Recvmsg و BPFCgroupGetsockopt و BPFCgroupSetsockopt و BPFTraceRawTp و BPFTraceFentry و BPFTraceFexit و BPFModifyReturn و BPFLsmMac و BPFTraceIter و BPFCgroupInet4Getpeername و BPFCgroupInet6Getpeername و BPFCgroupInet4Getsockname و BPFCgroupInet6Getsockname و BPFXdpDevmap و BPFCgroupInetSockRelease و BPFXdpCpumap و BPFSkLookup و BPFXdp و BPFSkSkbVerdict و BPFSkReuseportSelect و BPFSkReuseportSelectOrMigrate و BPFPerfEvent و BPFTraceKprobeMulti و BPFLsmCgroup و BPFStructOps و BPFNetfilter و BPFTcxIngress e BPFTcxEgress و BPFTraceUprobeMulti و BPFCgroupUnixConnect و BPFCgroupUnixSendmsg و BPFCgroupUnixRecvmsg و BPFCgroupUnixGetpeername و BPFCgroupUnixGetsockname و BPFNetkitPrimary و BPFNetkitPeer و BPFTraceKprobeSession و BPFTraceUprobeSession و BPFTraceFsession. سيقوم هذا بضبط خيار وصل bpffs المسمى delegate_attachs.

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

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

LockPersonality=
    يأخذ معاملًا منطقيًا. إذا ضُبط، يُغلق نداء النظام personality(2) بحيث لا يمكن تغيير نطاق تنفيذ النواة عن النطاق المبدئي أو السمة (personality) المحددة عبر توجيه Personality=. قد يكون هذا مفيدًا لتحسين الأمان، لأن محاكاة السمات الغريبة قد لا تكون مختبرة جيدًا وتعد مصدرًا للثغرات الأمنية.

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

MemoryDenyWriteExecute=
    يأخذ معاملًا منطقيًا. إذا ضُبط، تُحظر محاولات إنشاء تخطيطات ذاكرة قابلة للكتابة والتنفيذ في الوقت نفسه، أو تغيير تخطيطات الذاكرة الموجودة لتصبح قابلة للتنفيذ، أو تخطيط أجزاء الذاكرة المشتركة كأجزاء قابلة للتنفيذ. وتحديدًا، يُضاف مرشح نداءات النظام (أو يُفضل تفعيل فحص نواة مكافئ عبر prctl(2)) يرفض نداءات نظام mmap(2) التي تضبط كلا العلمين PROT_EXEC و PROT_WRITE، أو نداءات نظام mprotect(2) أو pkey_mprotect(2) التي تضبط العلم PROT_EXEC، ونداءات نظام shmat(2) التي تضبط العلم SHM_EXEC. لاحظ أن هذا الخيار غير متوافق مع البرامج والمكتبات التي تولد كود البرامج ديناميكيًا في وقت التشغيل، بما في ذلك محركات تنفيذ JIT، والمكدسات القابلة للتنفيذ، وميزة "trampoline" للكود في مختلف مجمعات لغة C. يحسن هذا الخيار أمان الخدمة، حيث يجعل من الصعب على استغلال البرمجيات الخبيثة تغيير الكود المشغل ديناميكيًا. ومع ذلك، يمكن الاحتيال على هذه الحماية إذا كانت الخدمة قادرة على الكتابة في نظام ملفات غير موصول بالعلم noexec (مثل /dev/shm)، أو إذا كانت قادرة على استخدام memfd_create(). يمكن منع ذلك بجعل أنظمة الملفات تلك غير قابلة للوصول من الخدمة (مثل InaccessiblePaths=/dev/shm) وتثبيت مرشحات نداءات نظام إضافية (SystemCallFilter=~memfd_create). لاحظ أن هذه الميزة متاحة بالكامل على معمارية x86-64، وجزئيًا على معمارية x86. وتحديدًا، حماية shmat() غير متاحة على معمارية x86. لاحظ أنه في الأنظمة التي تدعم واجهات ABI متعددة (مثل x86/x86-64) يُوصى بإيقاف واجهات ABI البديلة للخدمات، حتى لا يمكن استخدامها للاحتيال على قيود هذا الخيار. وتحديدًا، يُوصى بدمج هذا الخيار مع SystemCallArchitectures=native أو ما شابه.

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

RestrictRealtime=
    يأخذ معاملًا منطقيًا. إذا ضُبط، تُرفض أي محاولات لتمكين الجدولة في الوقت الحقيقي في أي عملية تابعة للوحدة. يحد هذا من الوصول إلى سياسات جدولة مهام الوقت الحقيقي مثل SCHED_FIFO أو SCHED_RR أو SCHED_DEADLINE. انظر sched(7) لتفاصيل حول سياسات الجدولة هذه. قد تُستخدم سياسات جدولة الوقت الحقيقي لاحتكار وقت المعالج لفترات زمنية أطول، وبالتالي قد تُستخدم لتعطيل النظام أو التسبب في حالات حجب الخدمة. لذا يوصى بتقييد الوصول إلى جدولة الوقت الحقيقي واقتصارها على البرامج القليلة التي تحتاجها فعليًا. القيمة المبدئية هي الإيقاف.

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

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

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

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

RemoveIPC=
    يأخذ معاملًا منطقيًا. إذا ضُبط، تُزال جميع كائنات IPC الخاصة بنظام System V وPOSIX المملوكة للمستخدم والمجموعة اللذين تُشغّل عمليات هذه الوحدة باسمهما عند إيقاف الوحدة. ليس لهذه التهيئة أي تأثير إلا إذا استُخدم واحد على الأقل من User= أو Group= أو DynamicUser=. وليس لها أي تأثير على كائنات IPC المملوكة للمستخدم الجَذر (root). وتحديدًا، يزيل هذا إشارات السيمافور الخاصة بـ System V، بالإضافة إلى مقاطع الذاكرة المشتركة وطوابير الرسائل الخاصة بـ System V وPOSIX. إذا استخدمت وحدات متعددة نفس المستخدم أو المجموعة، تُزال كائنات IPC عند إيقاف آخر وحدة منها. يُضمن هذا الإعداد تلقائيًا إذا ضُبط DynamicUser=.

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

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

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

    عند تشغيله، ينفذ ثلاث عمليات لكل عملية مُستدعاة: تُنشأ مساحة أسماء 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.

MountFlags=
    يأخذ إعدادًا لتوجيه الوصل: shared (مشترك)، أو slave (تابع)، أو private (خاص)، والذي يتحكم في ما إذا كانت نقاط وصل نظام الملفات في مساحات أسماء نظام ملفات المهيأة لعمليات هذه الوحدة ستستقبل أو توجه عمليات الوصل والفصل من مساحات أسماء نظام ملفات الأخرى. انظر mount(2) لتفاصيل حول توجيه الوصل، والرايات الثلاث للتوجيه على وجه الخصوص.

    يتحكم هذا الإعداد فقط في إعداد التوجيه النهائي المعمول به في جميع نقاط وصل مساحة أسماء نظام ملفات المنشأة لكل عملية في هذه الوحدة. ستعطّل إعدادات وحدة مساحات أسماء نظام ملفات الأخرى (انظر النقاش في PrivateMounts= أعلاه) توجيه الوصل والفصل ضمنيًا من عمليات الوحدة نحو المضيف عبر تغيير إعداد التوجيه لجميع نقاط الوصل في مساحة أسماء نظام ملفات للوحدة إلى slave أولًا. وضبط هذا الخيار على shared لا يعيد تأسيس التوجيه في هذه الحالة.

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

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

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

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

ترشيح استدعاءات النظام

SystemCallFilter=
    يأخذ قائمة مفصولة بمسافات لأسماء استدعاءات النظام أو مجموعات استدعاءات النظام. إذا استُخدم هذا الإعداد، فإن استدعاءات النظام التي تنفذها عمليات الوحدة باستثناء تلك المدرجة في القائمة ستُرفض (قائمة السماح). إذا كان المحرف الأول في القائمة هو "~", ينعكس التأثير: حيث تُرفض فقط استدعاءات النظام المدرجة (قائمة المنع). يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أقنعة المرشحات. إذا عُيّنت سلسلة فارغة، يُعاد ضبط المرشح، وتصبح جميع التعيينات السابقة بلا تأثير.

    الأوامر المسبوقة بـ "+" لا تخضع للترشيح. تُدرج استدعاءات النظام 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. مجموعات استدعاءات النظام مسبقة التعريف حاليًا
    المجموعة | الوصف
    @aio | الإدخال/الإخراج غير المتزامن (io_setup(2) و io_submit(2) والاستدعاءات ذات الصلة)
    @basic-io | استدعاءات النظام للإدخال/الإخراج الأساسي: القراءة والكتابة والتقديم وتكرار واصف الملف وإغلاقه (read(2) و write(2) والاستدعاءات ذات الصلة)
    @chown | تغيير ملكية الملف (chown(2) و fchownat(2) والاستدعاءات ذات الصلة)
    @clock | استدعاءات النظام لتغيير ساعة النظام (adjtimex(2) و settimeofday(2) والاستدعاءات ذات الصلة)
    @cpu-emulation | استدعاءات النظام لوظائف محاكاة المعالج (vm86(2) والاستدعاءات ذات الصلة)
    @debug | وظائف التنقيح ومراقبة الأداء والتتبع (ptrace(2) و perf_event_open(2) والاستدعاءات ذات الصلة)
    @file-system | عمليات نظام الملفات: فتح وإنشاء الملفات والأدلة للقراءة والكتابة، وإعادة تسميتها وإزالتها، وقراءة خصائص الملفات، أو إنشاء روابط صلبة ورمزية
    @io-event | استدعاءات نظام حلقة الأحداث (poll(2) و select(2) و epoll(7) و eventfd(2) والاستدعاءات ذات الصلة)
    @ipc | الأنابيب، و SysV IPC، وطوابير رسائل POSIX ووسائل IPC الأخرى (mq_overview(7) و svipc(7))
    @keyring | الوصول إلى حلقة مفاتيح النواة (keyctl(2) والاستدعاءات ذات الصلة)
    @memlock | قفل الذاكرة في رام (mlock(2) و mlockall(2) والاستدعاءات ذات الصلة)
    @module | تحميل وإلغاء تحميل وحدات النواة (init_module(2) و delete_module(2) والاستدعاءات ذات الصلة)
    @mount | وصل وفصل نظم الملفات (mount(2) و chroot(2) والاستدعاءات ذات الصلة)
    @network-io | مدخلات/مخرجات المقابس (بما في ذلك AF_UNIX المحلي): socket(7) و unix(7)
    @obsolete | غير معتادة، أو مهجورة، أو غير مدعومة (create_module(2) و gtty(2)، إلخ)
    @pkey | استدعاءات النظام التي تتعامل مع مفاتيح حماية الذاكرة (pkeys(7))
    @privileged | جميع استدعاءات النظام التي تحتاج إلى صلاحيات المستخدم الفائق (capabilities(7))
    @process | التحكم في العمليات، والتنفيذ، وعمليات مساحات الأسماء (clone(2) و kill(2) و namespaces(7)، إلخ)
    @raw-io | الوصول المباشر إلى منافذ الإدخال/الإخراج (ioperm(2) و iopl(2) و pciconfig_read()‎، إلخ)
    @reboot | استدعاءات النظام لإعادة التشغيل والتحضير لها (reboot(2) و kexec()‎، إلخ)
    @resources | استدعاءات النظام لتغيير حدود الموارد، ومعاملات الذاكرة والجدولة (setrlimit(2) و setpriority(2)، إلخ)
    @sandbox | استدعاءات النظام لعزل البرامج (seccomp(2)، واستدعاءات نظام Landlock، إلخ)
    @setuid | استدعاءات النظام لتغيير بيانات اعتماد معرف المستخدم ومعرف المجموعة (setuid(2) و setgid(2) و setresuid(2)، إلخ)
    @signal | استدعاءات النظام للتلاعب بإشارات العمليات ومعالجتها (signal(2) و sigprocmask(2)، إلخ)
    @swap | استدعاءات النظام لتمكين/تعطيل أجهزة التبديل (swapon(2) و swapoff(2))
    @sync | مزامنة الملفات والذاكرة مع القرص (fsync(2) و msync(2) والاستدعاءات ذات الصلة)
    @system-service | مجموعة معقولة من استدعاءات النظام التي تستخدمها خدمات النظام الشائعة، باستثناء أي استدعاءات ذات أغراض خاصة. هذه هي نقطة البداية الموصى بها لإنشاء قوائم السماح باستدعاءات النظام لخدمات النظام، لأنها تحتوي على ما تحتاجه عادةً خدمات النظام، ولكنها تستثني الواجهات المفرطة في الخصوصية. على سبيل المثال، تُستثنى واجهات البرمجة التالية: "@clock" و "@mount" و "@swap" و "@reboot".
    @timer | استدعاءات النظام لجدولة العمليات حسب الوقت (alarm(2) و timer_create(2)، إلخ)
    @known | جميع استدعاءات النظام التي تحددها النواة. تُعرّف هذه القائمة بشكل ثابت في systemd بناءً على إصدار النواة المتوفر عند إصدار نسخة systemd هذه. وستصبح قديمة تدريجيًا مع تحديث النواة.

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

SystemCallErrorNumber=
    يأخذ رقم خطأ "errno" (بين 1 و 4095) أو اسم خطأ مثل EPERM أو EACCES أو EUCLEAN، لإعادته عندما يُثار مرشح استدعاءات النظام المهيأ بـ SystemCallFilter=، بدلاً من إنهاء العملية فورًا. انظر errno(3) للقائمة الكاملة لرموز الأخطاء. عندما لا يُستخدم هذا الإعداد، أو عند تعيين سلسلة فارغة أو الإعداد الخاص "kill"، تُنهى العملية فورًا عند إثارة المرشح.

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

SystemCallArchitectures=
    يأخذ قائمة مفصولة بمسافات لمعرفات البنيات المعمارية لتضمينها في مرشح استدعاءات النظام. معرفات البنيات المعروفة هي نفسها الخاصة بـ ConditionArchitecture= الموصوفة في systemd.unit(5)، بالإضافة إلى x32 و mips64-n32 و mips64-le-n32، والمعرّف الخاص native. يُطابق المعرّف الخاص native ضمنيًا البنية المعمارية الأصلية للنظام (أو بمزيد من الدقة: البنية التي جُمع مدير النظام لأجلها). مبدئيًا، يُضبط هذا الخيار على قائمة فارغة، أي لا يُطبّق أي ترشيح.

    إذا استُخدم هذا الإعداد، فسيُسمح لعمليات هذه الوحدة فقط بإجراء استدعاءات النظام الأصلية (native)، واستدعاءات النظام للبنيات المعمارية المحددة. لأغراض هذا الخيار، تُعامل معمارية x32 على أنها تتضمن استدعاءات نظام x86-64. ومع ذلك، فإن هذا الإعداد لا يزال يؤدي غرضه، كما هو موضح أدناه، على x32.

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

    يمكن أيضًا تقييد بنيات استدعاءات النظام على مستوى النظام ككل عبر خيار SystemCallArchitectures= في التهيئة العامة. انظر systemd-system.conf(5) للتفاصيل.

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

SystemCallLog=
    يأخذ قائمة مفصولة بمسافات لأسماء استدعاءات النظام. إذا استُخدم هذا الإعداد، فسيُسجّل كل استدعاء نظام تنفذه عمليات الوحدة يطابق الاستدعاءات المدرجة. إذا كان المحرف الأول في القائمة هو "~", ينعكس التأثير: حيث تُسجّل جميع استدعاءات النظام باستثناء تلك المدرجة في القائمة. تستخدم هذه الميزة واجهات وضع الحوسبة الآمنة 2 (Secure Computing Mode 2) للنواة ('ترشيح seccomp') وهي مفيدة للمراجعة التدقيقية أو لإعداد بيئة عزل مخففة بأقل الحدود. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة تُدمج أقنعة المرشحات. إذا عُيّنت سلسلة فارغة، يُعيد ضبط المرشح، وتصبح جميع التعيينات السابقة بلا تأثير. ولا يؤثر هذا على الأوامر المسبوقة بـ "+".

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

البيئة

Environment=
    يعين متغيرات البيئة للعمليات المنفذة Orc. يزال الاقتباس عن كل سطر باستخدام القواعد الموصوفة في قسم "Quoting" في systemd.syntax(7) ويتحول إلى قائمة من تعيينات المتغيرات. إذا كنت بحاجة إلى تعيين قيمة تحتوي على مسافات أو علامة التساوي لمتغير ما، فضع علامات اقتباس حول التعيين بأكمله. لا يجرى توسيع المتغيرات داخل السلاسل النصية ولا يحمل المحرف "$" أي معنى خاص. يجرى توسيع المحددات، انظر قسم "Specifiers" في systemd.unit(5).

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

    يمكن أن تحتوي أسماء المتغيرات على أحرف 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= (انظر أدناه) لتمرير البيانات إلى عمليات الوحدة بشكل آمن.

EnvironmentFile=
    مماثل لـ Environment=، ولكنه يقرأ متغيرات البيئة من ملف نصي. يجب أن يحتوي الملف النصي على تعيينات متغيرات مفصولة بأسطر جديدة. الأسطر الفارغة، أو الأسطر التي لا تحتوي على فاصل "="، أو الأسطر التي تبدأ بـ ";" أو "#" سوف تُتجاهل، ويمكن استخدامها للتعليق. يجب أن يكون الملف مرمّزًا بـ UTF-8. المحارف الصالحة هي unicode scalar values[16] بخلاف unicode noncharacters[17]، و U+0000 NUL، و U+FEFF unicode byte order mark[18]. رموز التحكم بخلاف NUL مسموح بها.

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

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

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

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

    لاحظ أن متغيرات الصدفة مثل "$HOME" لا تُوسع في هذا المسار. استخدم محددات -"%" بدلاً من ذلك؛ على سبيل المثال، "%h" يُوسع إلى الدليل الرئيس للمستخدم.

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

    تتخطى الإعدادات القادمة من هذه الملفات الإعدادات المعينة باستخدام Environment=. إذا عُيّن نفس المتغير مرتين من هذه الملفات، فستُقرأ الملفات بالترتيب الذي حددت به، وسيتخطى الإعداد اللاحق الإعداد السابق.

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

    المتغيرات المعينة للعمليات المستدعاة بسبب هذا الإعداد تخضع للتخطي بواسطة تلك المضبوطة باستخدام Environment= أو EnvironmentFile=.

    مثال:

        PassEnvironment=VAR1 VAR2 VAR3

    يمرر ثلاثة متغيرات "VAR1" و "VAR2" و "VAR3" مع القيم المعينة لتلك المتغيرات في PID1.

    انظر environ(7) لتفاصيل حول متغيرات البيئة.

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

UnsetEnvironment=
    ألغِ صراحةً تعيينات متغيرات البيئة التي تُمرر عادةً من مدير الخدمة إلى العمليات المستدعاة لهذه الوحدة. يأخذ قائمة بأسماء المتغيرات أو تعيينات المتغيرات المفصولة بمسافات. يمكن تحديد هذا الخيار أكثر من مرة، وفي هذه الحالة يُلغى تعيين جميع المتغيرات/التعيينات المدرجة. إذا أُسندت سلسلة نصية فارغة إلى هذا الخيار، فستُصفّر قائمة متغيرات/تعيينات البيئة المراد إلغاء تعيينها. إذا حُدد تعيين متغير (أي: اسم متغير، متبوعًا بـ "="، متبوعًا بقيمته)، فسيُزال أي متغير بيئة يطابق هذا التعيين الدقيق. إذا حُدد اسم متغير (أي اسم متغير دون أي "=" أو قيمة تالية)، فسيُزال أي تعيين يطابق اسم المتغير بغض النظر عن قيمته. لاحظ أن تأثير UnsetEnvironment= يُطبَّق كخطوة نهائية عند تجميع قائمة البيئة الممررة إلى العمليات المنفذة. هذا يعني أنه قد يتراجع عن التعيينات من أي مصدر ضبط، بما في ذلك التعيينات التي تمت من خلال Environment= أو EnvironmentFile=، أو الموروثة من مجموعة متغيرات البيئة العالمية لمدير النظام، أو الموروثة عبر PassEnvironment=، أو المعينة بواسطة مدير الخدمة نفسه (مثل $NOTIFY_SOCKET وما شابه)، أو المعينة بواسطة وحدة PAM (في حال استخدام PAMName=).

    انظر "متغيرات البيئة في العمليات المولدة" أدناه للحصول على وصف لكيفية دمج هذه الإعدادات لتشكيل البيئة الموروثة. انظر environ(7) للحصول على معلومات عامة عن متغيرات البيئة.

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

التسجيل والإدخال/الإخراج القياسي

StandardInput=
    يتحكم في مكان اتصال واصف الملف 0 (STDIN) للعمليات المنفذة. يأخذ أحد الخيارات التالية: null، أو tty، أو tty-force، أو tty-fail، أو data، أو file:path، أو socket، أو fd:name.

    إذا اختير 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.

StandardOutput=
    يتحكم في مكان اتصال واصف الملف 1 (stdout) للعمليات المنفذة. يأخذ أحد الخيارات التالية: inherit، أو null، أو tty، أو journal، أو kmsg، أو journal+console، أو kmsg+console، أو file:path، أو append:path، أو truncate:path، أو socket، أو fd:name.

    يقوم الخيار 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. لاحظ أن تعيين هذا المعامل قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

StandardError=
    يتحكم في مكان اتصال واصف الملف 2 (stderr) للعمليات المنفذة. الخيارات المتاحة مطابقة لخيارات StandardOutput=، مع بعض الاستثناءات: إذا عُيّن إلى inherit فإن واصف الملف المستخدم للإخراج القياسي يُضاعَف لِيُستخدم للخطأ القياسي، بينما سَيستخدم fd:name اسم واصف ملف مبدئي هو "stderr".

    يكون هذا الإعداد مبدئيًا هو القيمة المعينة في DefaultStandardError= في systemd-system.conf(5)، والتي تكون مبدئيًا هي inherit. لاحظ أن تعيين هذا المعامل قد يؤدي إلى إضافة اعتماديات إضافية إلى الوحدة (انظر أعلاه).

StandardInputText=، StandardInputData=
    يضبط بيانات نصية أو ثنائية اختيارية لتمريرها عبر واصف الملف 0 (STDIN) إلى العمليات المنفذة. ليس لهذه الإعدادات أي تأثير ما لم يُعيّن StandardInput= إلى data (وهو الخيار المبدئي إذا لم يُضبط StandardInput= بخلاف ذلك، ولكن عُيّن StandardInputText=/StandardInputData=). استخدم هذا الخيار لتضمين بيانات إدخال العملية مباشرة في ملف الوحدة.

    يقبل StandardInputText= بيانات نصية اختيارية. تُفسَّر تتابعات هروب لغة C للمحارف الخاصة بالإضافة إلى محددات "%" المعتادة. في كل مرة يُستخدم فيها هذا الإعداد، يُلحق النص المحدد بمخزن بيانات الوحدة المؤقت، متبوعًا بمحرف سطر جديد (وبالتالي فإن كل استخدام يلحق سطرًا جديدًا بنهاية المخزن المؤقت). لاحظ أن المسافات البيضاء البادئة والختامية للأسطر المضبوطة بهذا الخيار تُزال. إذا حُدد سطر فارغ، فسيُمسح المخزن المؤقت (وبالتالي، لإدراج سطر فارغ، أضف "\n" إضافية إلى نهاية السطر أو بدايته).

    يقبل StandardInputData= بيانات ثنائية اختيارية، مَرموزة بـ Base64[22]. لا تُفسَّر أي تسلسلات هروب أو محددات. تُتجاهل أي مسافة بيضاء في النسخة المرموزة أثناء فك الترميز.

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

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

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

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

LogLevelMax=
    يعين الحد الأقصى لمستوى التسجيل لرسائل السجل المولدة بواسطة هذه الوحدة. يأخذ مستوى تسجيل syslog، وهو أحد الخيارات التالية: emerg (أدنى مستوى تسجيل، للرسائل ذات الأولوية القصوى فقط)، أو alert، أو crit، أو err، أو warning، أو notice، أو info، أو debug (أعلى مستوى تسجيل، وللرسائل ذات الأولوية الأدنى أيضًا). انظر syslog(3) للتفاصيل. مبدئيًا، لا يُتخطى الحد الأقصى لمستوى التسجيل.

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

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

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

LogExtraFields=
    يضبط حقول بيانات وصفية إضافية للسجل لتضمينها في جميع سجلات الأحداث التي تولدها العمليات المرتبطة بهذه الوحدة، بما في ذلك systemd. يأخذ هذا الإعداد تعيين حقل سجل واحد أو أكثر بتنسيق "FIELD=VALUE" مفصولة بمسافات بيضاء. انظر systemd.journal-fields(7) للحصول على تفاصيل حول مفهوم حقل السجل. على الرغم من أن آلية السجل الأساسية تسمح بقيم حقول ثنائية، فإن هذا الإعداد لا يقبل إلا قيم UTF-8 صالحة. لتضمين محارف مسافات في قيمة حقل السجل، أحط التعيين بعلامات اقتباس مزدوجة ("). تُوسَّع المحددات المعتادة في جميع التعيينات (انظر أدناه). لاحظ أن هذا الإعداد ليس مفيدًا فقط لإرفاق بيانات وصفية إضافية بسجلات أحداث الوحدة، ولكن بما أن جميع الحقول والقيم مفهرسة، فيمكن استخدامه أيضًا لتنفيذ مطابقة سجلات الأحداث عبر الوحدات المختلفة. أسند سلسلة نصية فارغة لتصفير القائمة.

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

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

LogRateLimitIntervalSec=, LogRateLimitBurst=
    يضبط حد المعدل الذي يُطبَّق على رسائل السجل المولدة بواسطة هذه الوحدة. إذا سُجّلت رسائل بواسطة خدمة ما في الفاصل الزمني المحدد بواسطة LogRateLimitIntervalSec= أكثر مما هو محدد في LogRateLimitBurst=، فستُسقط جميع الرسائل اللاحقة خلال الفاصل الزمني حتى ينتهي الفاصل الزمني. وتُولَّد رسالة تفيد بعدد الرسائل المسقطة. يمكن تحديد مواصفات الوقت لـ LogRateLimitIntervalSec= بالوحدات التالية: "s"، و "min"، و "h"، و "ms"، و "us". انظر systemd.time(7) للتفاصيل. تُعيّن الإعدادات المبدئية بواسطة RateLimitIntervalSec= و RateLimitBurst= المضبوطين في journald.conf(5). لاحظ أن هذا ينطبق فقط على رسائل السجل التي يُعالجها نظام التسجيل الفرعي، أي بواسطة systemd-journald.service(8). هذا يعني أنه إذا وُصل stderr الخاص بالخدمة مباشرة بملف عبر StandardOutput=file:... أو إعداد مشابه، فلن يُطبَّق حد المعدل على الرسائل المكتوبة بتلك الطريقة (ولكن سيُفرض على الرسائل المولدة عبر syslog(3) والدوال المشابهة).

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

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

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

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

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

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

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

LogNamespace=
    شغّل عمليات الوحدة في مساحة اسم السجل (journal namespace) المحددة. يتوقع سلسلة نصية قصيرة يحددها المستخدم لِتمييز مساحة الاسم. إذا لم يُستخدم، تُشغَّل عمليات الخدمة في مساحة اسم السجل المبدئية، أي أن تدفق سجلاتها يُجمع ويُعالج بواسطة systemd-journald.service. إذا استُخدم هذا الخيار، فإن أي بيانات سجل تولدها عمليات هذه الوحدة (بغض النظر عما إذا كانت عبر syslog()، أو تسجيل السجل الأصلي journal native، أو تسجيل stdout/stderr) تُجمع وتُعالج بواسطة مثيل من وحدة قالب systemd-journald@.service، التي تدير مساحة الاسم المحددة. تُخزن بيانات السجل في مخزن بيانات مستقل عن مخزن بيانات مساحة اسم السجل المبدئية. انظر systemd-journald.service(8) للحصول على تفاصيل حول مساحات اسم السجل.

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

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

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

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

SyslogIdentifier=
    يعين اسم العملية ("وسم syslog") لِتبدأ به أسطر السجل المرسلة إلى نظام التسجيل أو مخزن سجل النواة المؤقت. إذا لم يُضبط، يكون مبدئيًا هو اسم العملية للعملية المنفذة. يكون هذا الخيار مفيدًا فقط عندما يُعيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console) وينطبق فقط على رسائل السجل المكتوبة إلى stdout أو stderr.

SyslogFacility=
    يعين معرف مرفق syslog لاستخدامه عند التسجيل. أحد الخيارات التالية: kern، أو user، أو mail، أو daemon، أو auth، أو syslog، أو lpr، أو news، أو uucp، أو cron، أو authpriv، أو ftp، أو local0، أو local1، أو local2، أو local3، أو local4، أو local5، أو local6، أو local7. انظر syslog(3) للتفاصيل. يكون هذا الخيار مفيدًا فقط عندما يُعيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console)، وينطبق فقط على رسائل السجل المكتوبة إلى stdout أو stderr. ويكون مبدئيًا هو daemon.

SyslogLevel=
    مستوى تسجيل syslog المبدئي للاستخدام عند التسجيل في نظام التسجيل أو مخزن سجل النواة المؤقت. أحد الخيارات التالية: emerg، أو alert، أو crit، أو err، أو warning، أو notice، أو info، أو debug. انظر syslog(3) للتفاصيل. يكون هذا الخيار مفيدًا فقط عندما يُعيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console)، وينطبق فقط على رسائل السجل المكتوبة إلى stdout أو stderr. لاحظ أن الأسطر الفردية التي تخرجها العمليات المنفذة قد تبدأ بمستوى تسجيل مختلف يمكن استخدامه لتخطي مستوى التسجيل المبدئي المحدد هنا. يمكن تعطيل تفسير هذه البوادئ باستخدام SyslogLevelPrefix=، انظر أدناه. للتفاصيل، انظر sd-daemon(3). ويكون مبدئيًا هو info.

SyslogLevelPrefix=
    يأخذ معطى منطقيًا. إذا كان صحيحًا (true) وعُيّن StandardOutput= أو StandardError= إلى journal أو kmsg (أو نفس الإعدادات بالاشتراك مع +console)، فإن أسطر السجل التي تكتبها العملية المنفذة والتي تبدأ بمستوى تسجيل سَتعالج مع تعيين مستوى التسجيل هذا ولكن مع إزالة البادئة. إذا عُيّن إلى خطأ (false)، يُعطّل تفسير هذه البوادئ وتُمرر الأسطر المسجلة كما هي. ينطبق هذا فقط على رسائل السجل المكتوبة إلى stdout أو stderr. لمزيد من التفاصيل حول هذه البوادئ، انظر sd-daemon(3). ويكون مبدئيًا هو صحيح (true).

TTYPath=
    يعين عقدة جهاز الطرفية للاستخدام إذا كان الإدخال، أو الإخراج، أو الخطأ القياسي موصولًا بمثيرة TTY (انظر أعلاه). ويكون مبدئيًا هو /dev/console.

TTYReset=
    أعد ضبط جهاز الطرفية المحدد بـ TTYPath= قبل التنفيذ وبعده. هذا لا يمسح الشاشة (انظر TTYVTDisallocate= أدناه من أجل ذلك). ويكون مبدئيًا هو "no".

TTYVHangup=
    افصل جميع العملاء الذين فتحوا جهاز الطرفية المحدد بـ TTYPath= قبل التنفيذ وبعده. ويكون مبدئيًا هو "no".

TTYColumns=, TTYRows=
    اضبط حجم TTY المحددة بـ TTYPath=. إذا لم يُعين أو عُيّن إلى سلسلة نصية فارغة، فستُجرى محاولة لاسترداد أبعاد شاشة الطرفية عبر تتابعات ANSI، وإذا فشل ذلك، تُستخدم القيم المبدئية للنواة (عادةً 80x24).

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

TTYVTDisallocate=
    إذا كان جهاز الطرفية المحدد بـ TTYPath= عبارة عن طرفية وحدة تحكم افتراضية، فحاول إلغاء تخصيص TTY قبل التنفيذ وبعده. هذا يضمن مسح الشاشة ومخزن التمرير الخلفي المؤقت. إذا كان جهاز الطرفية من أي نوع آخر من TTY، تُجرى محاولة لمسح الشاشة عبر تتابعات ANSI. ويكون مبدئيًا هو "no".

بيانات الاستيثاق

LoadCredential=ID[:PATH]، LoadCredentialEncrypted=ID[:PATH]
    مرر وثيقة استيثاق (credential) إلى الوحدة. وثائق الاستيثاق هي كائنات نصية أو ثنائية محدودة الحجم يمكن تمريرها إلى عمليات الوحدة. وهي مخصصة في المقام الأول لتمرير مفاتيح التعمية (العامة والخاصة على حد سواء) أو الشهادات، أو معلومات حساب المستخدم، أو معلومات الهوية من المضيف إلى الخدمات، ولكن يمكن استخدامها بحرية لتمرير أي نوع من المعلومات محدودة الحجم إلى الخدمة. يمكن الوصول إلى البيانات من عمليات الوحدة عبر نظام الملفات، في موقع للقراءة فقط يكون (إذا كان ذلك ممكنًا ومسموحًا به) مدعومًا بذاكرة غير قابلة للتبديل (non-swappable). لا يمكن الوصول إلى البيانات إلا للمستخدم المرتبط بالوحدة، عبر إعدادات User=/DynamicUser= (بالإضافة إلى المستخدم الجذر superuser). عند توفره، يُصدَّر موقع وثائق الاستيثاق كمتغير البيئة $CREDENTIALS_DIRECTORY إلى عمليات الوحدة.

    يأخذ إعداد 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.

ImportCredential=GLOB
    مرّر استيثاقًا واحدًا أو أكثر إلى الوحدة. يأخذ اسم استيثاق سنحاول العثور على استيثاق استلمه مدير الخدمة نفسه تحت الاسم المحدد — والذي قد يُستخدم لنشر الاستيثاقات من بيئة مستدعية (مثلًا: مدير حاويات استدعى مدير الخدمة) إلى داخل خدمة. إذا كان اسم الاستيثاق عبارة عن نمط (glob)، تُمرّر جميع الاستيثاقات المطابقة للنمط إلى الوحدة. يُبحث عن الاستيثاقات المطابقة في استيثاقات النظام، واستيثاقات النظام المُعمّاة، وتحت /etc/credstore/، و/run/credstore/، و/usr/lib/credstore/، و/run/credstore.encrypted/، و/etc/credstore.encrypted/، و/usr/lib/credstore.encrypted/ بهذا الترتيب. عند العثور على استيثاقات متعددة تحمل نفس الاسم، يُستخدم أول واحد يُعثر عليه.

    يطبق تعبير النمط مجموعة فرعية تقييدية من 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.

SetCredential=ID:VALUE، SetCredentialEncrypted=ID:VALUE
    إعداد SetCredential= مشابه لـ LoadCredential= ولكنه يقبل قيمة حرفية لاستخدامها كبيانات للاستيثاق، بدلًا من مسار نظام ملفات لقراءة البيانات منه. لا تستخدم هذا الخيار للبيانات المفترض أن تكون سرية، لأنها متاحة للعمليات غير الممتلكة لصلاحيات عبر IPC. من الآمن فقط استخدامه لمعرفات المستخدم، ومواد المفتاح العام، والبيانات غير الحساسة المشابهة. لكل شيء آخر، استخدم LoadCredential=. لتضمين بيانات ثنائية في بيانات الاستيثاق، استخدم الهروب بأسلوب C (أي "\n" لتضمين سطر جديد، أو "\x00" لتضمين بايت NUL).

    إعداد SetCredentialEncrypted= مطابق لـ SetCredential= ولكنه يتوقع استيثاقًا مُعمّى بصيغة حرفية كقيمة. يسمح هذا بتضمين استيثاقات سرية بشكل آمن مباشرة في ملفات الوحدة. استخدم مفتاح -p لـ systemd-creds(1) لتوليد أسطر SetCredentialEncrypted= مناسبة مباشرة من الاستيثاقات بنص صريح. للمزيد من التفاصيل انظر LoadCredentialEncrypted= أعلاه.

    عند العثور على استيثاقات متعددة تحمل نفس الاسم، تكون الأولوية للاستيثاقات التي عُثر عليها بواسطة LoadCredential= و LoadCredentialEncrypted= و ImportCredential= على الاستيثاقات التي عُثر عليها بواسطة SetCredential=. وعليه، سيعمل SetCredential= كمبدئي إذا لم يُعثر على أي استيثاقات بواسطة أي مما سبق. في هذه الحالة، عدم القدرة على استرجاع الاستيثاق من المسار المحدد في LoadCredential= أو LoadCredentialEncrypted= لا يُعد خطأ جسيمًا.

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

توافقية SYSTEM V

UtmpIdentifier=
    يأخذ سلسلة معرف من أربعة محارف لمدخل utmp(5) و wtmp لهذه الخدمة. يجب ضبط هذا فقط للخدمات مثل تنفيذات getty (مثل agetty(8)) حيث يجب إنشاء وتنظيف مدخلات utmp/wtmp قبل وبعد التنفيذ، أو للخدمات التي ستُنفذ كما لو كانت مُشغلة بواسطة عملية getty (انظر أدناه). إذا كانت السلسلة المضبوطة أطول من أربعة محارف، فستُقتطع وتُستخدم المحارف الأربعة الأخيرة. يفسّر هذا الإعداد استبدالات السلاسل بنمط %I. هذا الإعداد غير مضبوط مبدئيًا، أي لا تُنشأ أو تُنظف أي مدخلات utmp/wtmp لهذه الخدمة.

UtmpMode=
    يأخذ إحدى القيم "init" أو "login" أو "user". إذا ضُبط UtmpIdentifier=، يتحكم في نوع مدخلات utmp(5)/wtmp المُنشأة لهذه الخدمة. ليس لهذا الإعداد أي تأثير ما لم يُضبط UtmpIdentifier= أيضًا. إذا ضُبط على "init"، يُنشأ مدخل INIT_PROCESS فقط ويجب أن تطبق العملية المستدعاة منطق utmp/wtmp متوافقًا مع getty. إذا ضُبط على "login"، يُنشأ أولًا مدخل INIT_PROCESS، متبوعًا بمدخل LOGIN_PROCESS. في هذه الحالة، يجب أن تطبق العملية المستدعاة منطق utmp/wtmp متوافقًا مع login(1). إذا ضُبط على "user"، يُنشأ أولًا مدخل INIT_PROCESS، ثم مدخل LOGIN_PROCESS وأخيرًا مدخل USER_PROCESS. في هذه الحالة، قد تكون العملية المستدعاة أي عملية مناسبة لتُشغل كقائد جلسة. القيمة المبدئية هي "init".

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

متغيرات البيئة في العمليات المُنشأة

العمليات التي يبدأها مدير الخدمة تُنفذ مع كتلة متغيرات بيئة مُجمّعة من مصادر متعددة. العمليات التي يبدأها مدير خدمة النظام لا ترث عمومًا متغيرات البيئة المضبوطة لمدير الخدمة نفسه (لكن يمكن تغيير هذا عبر PassEnvironment=)، لكن العمليات التي تبدأها نسخ مدير خدمة المستخدم ترث عمومًا جميع متغيرات البيئة المضبوطة لمدير الخدمة نفسه.

لكل عملية مستدعاة، تُجمع قائمة متغيرات البيئة المضبوطة من المصادر التالية:

    • المتغيرات المضبوطة عالميًا لمدير الخدمة، باستخدام إعداد DefaultEnvironment= في systemd-system.conf(5)، أو خيار سطر أوامر النواة systemd.setenv= المفهوم بواسطة systemd(1)، أو عبر فعل set-environment الخاص بـ systemctl(1).

    • المتغيرات المُعرّفة بواسطة مدير الخدمة نفسه (انظر القائمة أدناه).

    • المتغيرات المضبوطة في كتلة متغيرات بيئة مدير الخدمة نفسه (خاضعة لـ PassEnvironment= لمدير خدمة النظام).

    • المتغيرات المضبوطة عبر Environment= في ملف الوحدة.

    • المتغيرات المقروءة من الملفات المحددة عبر EnvironmentFile= في ملف الوحدة.

    • المتغيرات المضبوطة بواسطة أي ملاحق PAM في حال كان PAMName= ساري المفعول، راجع pam_env(8).

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

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

تلميح: systemd-run -P env و systemd-run --user -P env تطبع كتل بيئة خدمة النظام والمستخدم الفعلية.

  متغيرات البيئة المضبوطة أو المنشورة بواسطة مدير الخدمة

تُنشر متغيرات البيئة التالية بواسطة مدير الخدمة أو تُنشأ داخليًا لكل عملية مُستدعاة:

$PATH
    قائمة مفصولة بنقطتين من المجلدات لاستخدامها عند إطلاق الملفات التنفيذية. يستخدم systemd قيمة ثابتة هي "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" في مدير النظام. في حالة مدير المستخدم، قد تُضبط مسارات مختلفة بواسطة التوزيعة. يُنصح بعدم الاعتماد على ترتيب المدخلات، وأن يوجد برنامج واحد فقط يحمل اسمًا معينًا في $PATH.

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

$LANG
    الإعدادات المحلية (Locale). يمكن ضبطها في locale.conf(5) أو في سطر أوامر النواة (طالع systemd(1) و kernel-command-line(7)).

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

$USER, $LOGNAME, $HOME, $SHELL
    اسم المستخدم (مرتين)، مجلد المنزل، وصدفة الولوج. يُضبط $USER دون قيد، بينما لا تُضبط $HOME و $LOGNAME و $SHELL إلا للوحدات التي ضُبط فيها User= وكان SetLoginEnvironment= غير مضبوط أو مضبوطًا إلى true. بالنسبة لخدمات المستخدم، عادةً ما تُورث هذه المتغيرات من مدير المستخدم نفسه. طالع passwd(5).

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

$INVOCATION_ID
    يحتوي على معرِّف عشوائي فريد بطول 128 بت يحدد كل دورة تشغيل للوحدة، منسق كسلسلة ست عشرية من 32 حرفًا. يُخصص معرِّف جديد في كل مرة تتغير فيها الوحدة من حالة غير نشطة إلى حالة التنشيط أو حالة نشطة، ويمكن استخدامه لتحديد دورة التشغيل المحددة هذه، لا سيما في البيانات المخزنة دون اتصال، مثل دفتر اليومية. يُمرر نفس المعرِّف إلى جميع العمليات التي تُشغَّل كجزء من الوحدة.

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

$XDG_RUNTIME_DIR
    المجلد المراد استخدامه لكائنات وقت التشغيل (مثل كائنات IPC) والحالة المتطايرة. يُضبط لجميع الخدمات التي تشغلها نسخة systemd الخاصة بالمستخدم، وكذلك لأي خدمات نظام تستخدم PAMName= مع مكدس PAM يتضمن pam_systemd. طالع أدناه و pam_systemd(8) لمزيد من المعلومات.

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

$RUNTIME_DIRECTORY, $STATE_DIRECTORY, $CACHE_DIRECTORY, $LOGS_DIRECTORY, $CONFIGURATION_DIRECTORY
    المسارات المطلقة للمجلدات المُعرَّفة بـ RuntimeDirectory= و StateDirectory= و CacheDirectory= و LogsDirectory= و ConfigurationDirectory= عند استخدام تلك الإعدادات.

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

$CREDENTIALS_DIRECTORY
    مسار مطلق للمجلد الخاص بالوحدة الذي يحتوي على أوراق الاعتماد المضبوطة عبر ImportCredential=/LoadCredential=/SetCredential=. يُعلَّم المجلد كـ للقراءة فقط ويُوضع في ذاكرة غير قابلة للتبديل (إذا كان ذلك مدعومًا ومسموحًا به)، ولا يمكن الوصول إليه إلا بواسطة UID المقترن بالوحدة عبر User= أو DynamicUser= (وكذلك المستخدم الخارق).

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

$TMPDIR
    يُضبط متغير البيئة إلى "/tmp" عند تحديد PrivateTmp=disconnected مع DefaultDependencies=no وبدون RootDirectory=/RootImage= و RequiresMountsFor=/WantsMountsFor= لـ /var/. طالع الشرح الخاص بـ PrivateTmp= أعلاه.

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

$MAINPID
    معرِّف العملية (PID) في يونكس للعملية الرئسية للوحدة إذا كان معروفًا. لا يُضبط هذا إلا لعمليات التحكم كما يُستدعى بواسطة ExecReload= وما شابه.

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

$MAINPIDFDID
    معرِّف الـ inode بطول 64 بت لوصف الملف الذي أرجعته pidfd_open(3) للعملية الرئسية (إذا كان مدعومًا). لا يُضبط هذا إلا لعمليات التحكم كما يُستدعى بواسطة ExecReload= وما شابه.

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

$MANAGERPID
    معرِّف العملية (PID) لنسخة مدير خدمة systemd الخاصة بالمستخدم، ويُضبط للعمليات التي تنبثق عنها.

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

$MANAGERPIDFDID
    معرِّف الـ inode لـ pidfd_open() (طالع أعلاه) لنسخة مدير خدمة systemd الخاصة بالمستخدم، ويُضبط للعمليات التي تنبثق عنها.

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

$LISTEN_FDS، $LISTEN_PID، $LISTEN_PIDFDID، $LISTEN_FDNAMES
    معلومات حول واصفات الملفات الممررة إلى خدمة من أجل تفعيل المقبس. طالع sd_listen_fds(3).

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

$NOTIFY_SOCKET
    المقبس الذي تتحدث إليه sd_notify(). طالع sd_notify(3).

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

$WATCHDOG_PID, $WATCHDOG_USEC
    معلومات حول إشعارات إبقاء الاتصال (keep-alive) للمراقب (watchdog). طالع sd_watchdog_enabled(3).

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

$SYSTEMD_EXEC_PID
    معرِّف العملية (PID) لعملية الوحدة (مثل العملية التي استُدعيت بواسطة ExecStart=). يمكن للعملية الابنة استخدام هذه المعلومات لتحديد ما إذا كانت العملية مُستدعاة مباشرةً بواسطة مدير الخدمة أو بشكل غير مباشر كابن لعملية أخرى، وذلك بمقارنة هذه القيمة بـ PID الحالي (على غرار المخطط المستخدم في sd_listen_fds(3) مع $LISTEN_PID و $LISTEN_FDS).

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

$TERM
    نوع الطرفية، يُضبط فقط للوحدات المتصلة بطرفية (StandardInput=tty أو StandardOutput=tty أو StandardError=tty). طالع termcap(5).

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

$LOG_NAMESPACE
    يحتوي على اسم مساحة اسم السجلات المحددة عند استخدام إعداد الخدمة LogNamespace=.

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

$JOURNAL_STREAM
    إذا كان الإخراج القياسي أو خطأ الإخراج القياسي للعمليات المُنفَّذة متصلاً بدفتر اليومية (على سبيل المثال، عن طريق ضبط StandardError=journal)، فإن $JOURNAL_STREAM يحتوي على أرقام الجهاز والـ inode لواصف ملف الاتصال، منسقة بالنظام العشري ومفصولة بنقطتين (":"). يسمح هذا للعمليات المُستدعاة باكتشاف ما إذا كان إخراجها القياسي أو خطأ الإخراج القياسي متصلاً بدفتر اليومية بأمان. يجب مقارنة أرقام الجهاز والـ inode لواصفات الملفات بالقيم المحددة في متغير البيئة لتحديد ما إذا كان إخراج العملية لا يزال متصلاً بدفتر اليومية. لاحظ أنه لا يكفي عمومًا التحقق فقط مما إذا كان $JOURNAL_STREAM مضبوطًا على الإطلاق، حيث قد تستدعي الخدمات عمليات خارجية تستبدل إخراجها القياسي أو خطأ الإخراج القياسي الخاص بها، دون إلغاء ضبط متغير البيئة.

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

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

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

$SERVICE_RESULT
    يُستخدم فقط لنوع وحدة الخدمة. يُمرر متغير البيئة هذا إلى جميع عمليات ExecStop= و ExecStopPost=، ويُرمِّز "نتيجة" الخدمة. حاليًا، القيم التالية مُعرَّفة:

    جدول 6. قيم $SERVICE_RESULT المُعرَّفة
    القيمة | المعنى
    "success" | عملت الخدمة بنجاح وخرجت بشكل نظيف.
    "protocol" | حدث انتهاك للبروتوكول: لم تتخذ الخدمة الخطوات المطلوبة بواسطة ضبط وحدتها (تحديدًا ما هو مضبوط في إعداد Type= الخاص بها).
    "timeout" | انتهت مهلة إحدى الخطوات.
    "exit-code" | خرجت عملية الخدمة برمز خروج غير صفري؛ طالع $EXIT_CODE أدناه لمعرفة رمز الخروج الفعلي المُرجع.
    "signal" | أُنهيت عملية خدمة بشكل غير طبيعي بواسطة إشارة، دون تفريغ الذاكرة (core dump). طالع $EXIT_CODE أدناه لمعرفة الإشارة الفعلية التي تسببت في الإنهاء.
    "core-dump" | أُنهيت عملية خدمة بشكل غير طبيعي بإشارة مع تفريغ الذاكرة (core dump). طالع $EXIT_CODE أدناه لمعرفة الإشارة التي تسببت في الإنهاء.
    "watchdog" | عُلِّق نبض الحفاظ على العمل (Watchdog keep-alive ping) للخدمة، ولكن فُوِّت الموعد النهائي.
    "exec-condition" | لم تعمل الخدمة لأن ExecCondition= فشل (أي أن أمره خرج بحالة خروج تتراوح من 1 إلى 254 (شاملة)).
    "oom-kill" | أُنهيت عملية الخدمة بواسطة قاتل نقص الذاكرة (OOM killer).
    "start-limit-hit" | عُرِّف حد للبدء للوحدة ووُصِل إليه، مما تسبب في فشل الوحدة في البدء. راجع StartLimitIntervalSec= و StartLimitBurst= الخاصَّيْن بـ systemd.unit(5) للتفاصيل.
    "resources" | حالة شاملة في حال فشلت عملية للنظام.

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

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

$EXIT_CODE, $EXIT_STATUS
    عُرِّف فقط لنوع وحدة الخدمة. تُمرَّر متغيرات البيئة هذه إلى جميع عمليات ExecStop= و ExecStopPost= وتحتوي على معلومات حالة/رمز الخروج لعملية الخدمة الرئيسية. لمعرفة التعريف الدقيق لرمز وحالة الخروج، راجع wait(2). $EXIT_CODE هو أحد القيم "exited"، أو "killed"، أو "dumped". يحتوي $EXIT_STATUS على رمز الخروج الرقمي منسقاً كسلسلة نصية إذا كان $EXIT_CODE هو "exited"، واسم الإشارة في جميع الحالات الأخرى. لاحظ أن متغيرات البيئة هذه تُضبط فقط إذا نجح مدير الخدمة في بدء وتحديد العملية الرئيسية للخدمة.

    جدول 7. ملخص لقيم متغير نتيجة الخدمة الممكنة
    $SERVICE_RESULT | $EXIT_CODE | $EXIT_STATUS
    "success" | "killed" | "HUP", "INT", "TERM", "PIPE"
     | "exited" | "0"
    "protocol" | not set | not set
     | "exited" | "0"
    "timeout" | "killed" | "TERM", "KILL"
     | "exited" | "0", "1", "2", "3", ..., "255"
    "exit-code" | "exited" | "1", "2", "3", ..., "255"
    "signal" | "killed" | "HUP", "INT", "KILL", ...
    "core-dump" | "dumped" | "ABRT", "SEGV", "QUIT", ...
    "watchdog" | "dumped" | "ABRT"
     | "killed" | "TERM", "KILL"
     | "exited" | "0", "1", "2", "3", ..., "255"
    "exec-condition" | "exited" | "1", "2", "3", "4", ..., "254"
    "oom-kill" | "killed" | "TERM", "KILL"
    "start-limit-hit" | not set | not set
    "resources" | أي مما سبق | أي مما سبق
    ملاحظة: قد تُنهى العملية أيضًا بواسطة إشارة لم يرسلها systemd. وبشكل خاص، قد ترسل العملية إشارة تعسفية إلى نفسها في معالج لأي من الإشارات غير القابلة للقناع. ومع ذلك، في صفوف "timeout" و "watchdog" أعلاه، أُدرجت فقط الإشارات التي يرسلها systemd. علاوة على ذلك، باستخدام SuccessExitStatus=، يمكن التصريح عن حالات خروج إضافية للإشارة إلى الإنهاء النظيف، وهو ما لا ينعكس في هذا الجدول.

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

$MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS, $MONITOR_INVOCATION_ID, $MONITOR_UNIT
    عُرِّف فقط لنوع وحدة الخدمة. تُمرَّر متغيرات البيئة تلك إلى جميع عمليات ExecStart= و ExecStartPre= التي تعمل في الخدمات المثارَة بواسطة تبعيات OnFailure= أو OnSuccess=.

    تأخذ المتغيرات $MONITOR_SERVICE_RESULT و $MONITOR_EXIT_CODE و $MONITOR_EXIT_STATUS نفس القيم الخاصة بعمليات ExecStop= و ExecStopPost=. تُضبط المتغيرات $MONITOR_INVOCATION_ID و $MONITOR_UNIT على معرف الاستدعاء واسم الوحدة للخدمة التي أثارت التبعية.

    لاحظ أنه عندما تحدد خدمات متعددة نفس الوحدة كمعالج OnFailure= أو OnSuccess= خاص بها، فإن هذه المتغيرات لن تُمرَّر. فكِّر في استخدام وحدة معالجة قالب (template handler unit) لتلك الحالة بدلاً من ذلك: "OnFailure=handler@%n.service" للوحدات غير المقولبة، أو "OnFailure=handler@%p-%i.service" للوحدات المقولبة.

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

$PIDFILE
    المسار إلى ملف PID المضبوط، في حالة تشعب العملية نيابةً عن خدمة تستخدم الإعداد PIDFile=، طالع systemd.service(5) للتفاصيل. قد يستخدم كود الخدمة متغير البيئة هذا لإنشاء ملف PID آلياً في الموقع المضبوط في ملف الوحدة. ضُبط هذا الحقل على مسار مطلق في نظام الملفات.

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

$REMOTE_ADDR, $REMOTE_PORT
    إذا كانت هذه وحدة بدأت عبر تفعيل المقبس لكل اتصال (أي عبر وحدة مقبس مع Accept=yes)، فإن متغيرات البيئة هذه تحتوي على معلومات حول الطرف البعيد لاتصال المقبس.

    بالنسبة لاتصالات IPv4 و IPv6، يحتوي $REMOTE_ADDR على عنوان IP، ويحتوي $REMOTE_PORT على رقم المنفذ الخاص بالطرف البعيد.

    بالنسبة لاتصالات مقبس AF_UNIX، يحتوي $REMOTE_ADDR إما على مسار نظام ملفات المقبس البعيد الذي يبدأ بشرطة مائلة ("/")، أو عنوانه في فضاء الاسم المجرد الذي يبدأ برمز ("@")، أو يكون غير معين في حالة المقبس غير المسمى. $REMOTE_PORT غير معين لمقابس AF_UNIX.

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

$SO_COOKIE
    إذا كانت هذه وحدة بدأت عبر تفعيل المقبس لكل اتصال (أي عبر وحدة مقبس مع Accept=yes)، فإن متغير البيئة هذا يحتوي على ملف تعريف ارتباط (cookie) مقبس لينكس، منسقاً كعدد صحيح عشري. يمكن الحصول على ملف تعريف ارتباط المقبس بخلاف ذلك عبر getsockopt(7).

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

$TRIGGER_UNIT, $TRIGGER_PATH, $TRIGGER_TIMER_REALTIME_USEC, $TRIGGER_TIMER_MONOTONIC_USEC
    إذا كانت الوحدة قد فُعلت ديناميكياً (مثلاً: وحدة مسار أو وحدة مؤقت مقابلة)، فستُمرر الوحدة التي أطلقتها ومعلومات أخرى معتمدة على النوع عبر هذه المتغيرات. يُلاحظ أن هذه المعلومات تُقدم على أساس أفضل جهد. على سبيل المثال، ستُدمج المثيرات المتعددة التي تحدث تالياً لبعضها البعض وسيُبلغ عن واحد منها فقط، دون ضمان حول أيهما سيكون. بسبب هذا، سيكون هذا المتغير في معظم الحالات للإعلام في المقام الأول، أي مفيد لأغراض التنقيح، وهو فاقد للبيانات، ولا ينبغي الاعتماد عليه لنقل سبب شامل للتفعيل.

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

$MEMORY_PRESSURE_WATCH, $MEMORY_PRESSURE_WRITE
    إذا كانت مراقبة ضغط الذاكرة مفعلة لوحدة الخدمة هذه، فالمسار المراقب والبيانات المراد كتابتها فيه. انظر معالجة ضغط الموارد[27] للتفاصيل حول هذه المتغيرات وبيانات بروتوكول الخدمة التي تنقلها.

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

$CPU_PRESSURE_WATCH, $CPU_PRESSURE_WRITE
    إذا كانت مراقبة ضغط وحدة المعالجة المركزية مفعلة لوحدة الخدمة هذه، فالمسار المراقب والبيانات المراد كتابتها فيه. انظر معالجة ضغط الموارد[27] للتفاصيل حول هذه المتغيرات وبيانات بروتوكول الخدمة التي تنقلها.

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

$IO_PRESSURE_WATCH, $IO_PRESSURE_WRITE
    إذا كانت مراقبة ضغط الإدخال/الإخراج مفعلة لوحدة الخدمة هذه، فالمسار المراقب والبيانات المراد كتابتها فيه. انظر معالجة ضغط الموارد[27] للتفاصيل حول هذه المتغيرات وبيانات بروتوكول الخدمة التي تنقلها.

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

$FDSTORE
    العدد الأقصى لواصفات الملفات التي يمكن تخزينها في المدير للخدمة. يُضبط هذا المتغير عند تفعيل مخزن واصفات الملفات للخدمة، أي FileDescriptorStoreMax= مضبوط على قيمة غير صفرية (طالع systemd.service(5) للتفاصيل). قد تتحقق التطبيقات من متغير البيئة هذا قبل إرسال واصفات الملفات إلى مدير الخدمة عبر sd_pid_notify_with_fds(3).

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

$DEBUG_INVOCATION
    إذا كان RestartMode=debug مضبوطاً، وفشلت محاولة سابقة لبدء الوحدة، فسيُمرر متغير البيئة هذا إلى الخدمة للإشارة إلى أنه ينبغي تفعيل تسجيل إضافي عند البدء. طالع systemd.service(5) لمزيد من التفاصيل.

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

بالنسبة لخدمات النظام، عند تفعيل PAMName= وكون pam_systemd جزءاً من رزمة PAM المختارة، قد تُضبط متغيرات بيئة إضافية معرفة بواسطة systemd للخدمات. وتحديداً، هذه هي $XDG_SEAT، و $XDG_VTNR، طالع pam_systemd(8) للتفاصيل.

رموز خروج العملية

عند استدعاء عملية وحدة، ربما يفشل مدير الخدمة في تطبيق معاملات التنفيذ المضبوطة بالإعدادات أعلاه. في تلك الحالة ستخرج عملية الخدمة المنشأة بالفعل برمز خروج غير صفري قبل تنفيذ سطر الأوامر المضبوط. (أو بعبارة أخرى، ربما تخرج العملية الابنة برموز الخطأ هذه، بعد إنشائها بواسطة نداء النظام fork(2)، ولكن قبل استدعاء نداء النظام المطابق execve(2).) تحديداً، تُستخدم رموز الخروج المعرفة بواسطة مكتبة C، ومواصفة LSB، ومدير خدمة systemd نفسه.

رموز خروج الخدمة الأساسية التالية معرفة بواسطة مكتبة C.

جدول 8. رموز خروج مكتبة C الأساسية
رمز الخروج | الاسم الرمزي | الوصف
0 | EXIT_SUCCESS | رمز نجاح عام.
1 | EXIT_FAILURE | فشل عام أو خطأ غير محدد.

رموز خروج الخدمة التالية معرفة بواسطة مواصفة LSB[28].

جدول 9. رموز خروج خدمة LSB
رمز الخروج | الاسم الرمزي | الوصف
2 | EXIT_INVALIDARGUMENT | وسائط غير صالحة أو فائضة.
3 | EXIT_NOTIMPLEMENTED | ميزة غير مطبقة.
4 | EXIT_NOPERMISSION | المستخدم لديه امتيازات غير كافية.
5 | EXIT_NOTINSTALLED | البرنامج غير مثبت.
6 | EXIT_NOTCONFIGURED | البرنامج غير مضبوط.
7 | EXIT_NOTRUNNING | البرنامج لا يعمل.

تقترح مواصفة LSB أن رموز الخطأ 200 وما فوق محجوزة للتنفيذات. بعضها يُستخدم بواسطة مدير الخدمة للإشارة إلى مشاكل أثناء استدعاء العملية:

جدول 10. رموز خروج خاصة بـ systemd
رمز الخروج | الاسم الرمزي | الوصف
200 | EXIT_CHDIR | فشل التغيير إلى دليل العمل المطلوب. طالع WorkingDirectory= أعلاه.
201 | EXIT_NICE | فشل ضبط أولوية جدولة العملية (مستوى nice). طالع Nice= أعلاه.
202 | EXIT_FDS | فشل إغلاق واصفات الملفات غير المرغوب فيها، أو تعديل واصفات الملفات الممررة.
203 | EXIT_EXEC | فشل تنفيذ العملية الفعلي (تحديداً، نداء النظام execve(2)). على الأرجح يسبب هذا ملف تنفيذي مفقود أو غير قابل للوصول.
204 | EXIT_MEMORY | فشل تنفيذ إجراء بسبب نقص الذاكرة.
205 | EXIT_LIMITS | فشل في ضبط حدود الموارد. انظر LimitCPU= والإعدادات المتعلقة أعلاه.
206 | EXIT_OOM_ADJUST | فشل في ضبط إعداد OOM. انظر OOMScoreAdjust= أعلاه.
207 | EXIT_SIGNAL_MASK | فشل في ضبط قناع إشارة العملية.
208 | EXIT_STDIN | فشل في إعداد الدخل القياسي. انظر StandardInput= أعلاه.
209 | EXIT_STDOUT | فشل في إعداد الخرج القياسي. انظر StandardOutput= أعلاه.
210 | EXIT_CHROOT | فشل في تغيير دليل الجذر (chroot(2)). انظر RootDirectory=/RootImage= أعلاه.
211 | EXIT_IOPRIO | فشل في إعداد أولوية جدولة دخل/خرج. انظر IOSchedulingClass=/IOSchedulingPriority= أعلاه.
212 | EXIT_TIMERSLACK | فشل في إعداد تراخي المؤقت. انظر TimerSlackNSec= أعلاه.
213 | EXIT_SECUREBITS | فشل في ضبط بتات أمن العملية. انظر SecureBits= أعلاه.
214 | EXIT_SETSCHEDULER | فشل في إعداد جدولة المعالج. انظر CPUSchedulingPolicy=/CPUSchedulingPriority= أعلاه.
215 | EXIT_CPUAFFINITY | فشل في إعداد تقارب المعالج. انظر CPUAffinity= أعلاه.
216 | EXIT_GROUP | فشل في تحديد أو تغيير بيانات اعتماد المجموعة. انظر Group=/SupplementaryGroups= أعلاه.
217 | EXIT_USER | فشل في تحديد أو تغيير بيانات اعتماد المستخدم، أو في إعداد تجميع مساحات أسماء المستخدم. انظر User=/PrivateUsers= أعلاه.
218 | EXIT_CAPABILITIES | فشل في إسقاط الصلاحيات، أو تطبيق الصلاحيات المحيطة. انظر CapabilityBoundingSet=/AmbientCapabilities= أعلاه.
219 | EXIT_CGROUP | فشل إعداد مجموعة تحكم الخدمة.
220 | EXIT_SETSID | فشل في إنشاء جلسة عملية جديدة.
221 | EXIT_CONFIRM | أُلغِي التنفيذ من قبل المستخدم. انظر إعداد سطر الأوامر للنواة systemd.confirm_spawn= في kernel-command-line(7) للحصول على تفاصيل.
222 | EXIT_STDERR | فشل في إعداد خرج الخطأ القياسي. انظر StandardError= أعلاه.
224 | EXIT_PAM | فشل في إعداد جلسة PAM. انظر PAMName= أعلاه.
225 | EXIT_NETWORK | فشل في إعداد تجميع مساحات أسماء الشبكة. انظر PrivateNetwork= أعلاه.
226 | EXIT_NAMESPACE | فشل في إعداد تجميع مساحات أسماء الوصل، UTS، أو IPC. انظر ReadOnlyPaths=، ProtectHostname=، PrivateIPC=، والإعدادات المتعلقة أعلاه.
227 | EXIT_NO_NEW_PRIVILEGES | فشل في تعطيل الامتيازات الجديدة. انظر NoNewPrivileges=yes أعلاه.
228 | EXIT_SECCOMP | فشل في تطبيق مرشحات نداءات النظام. انظر SystemCallFilter= والإعدادات المتعلقة أعلاه.
229 | EXIT_SELINUX_CONTEXT | فشل تحديد أو تغيير سياق SELinux. انظر SELinuxContext= أعلاه.
230 | EXIT_PERSONALITY | فشل في إعداد نطاق التنفيذ (الشخصية). انظر Personality= أعلاه.
231 | EXIT_APPARMOR_PROFILE | فشل في التحضير لتغيير تشكيلة AppArmor. انظر AppArmorProfile= أعلاه.
232 | EXIT_ADDRESS_FAMILIES | فشل في تقييد عائلات العناوين. انظر RestrictAddressFamilies= أعلاه.
233 | EXIT_RUNTIME_DIRECTORY | فشل في إعداد دليل وقت التشغيل. انظر RuntimeDirectory= والإعدادات ذات الصلة أعلاه.
235 | EXIT_CHOWN | فشل في ضبط ملكية المقبس. يُستخدم لوحدات المقابس فقط.
236 | EXIT_SMACK_PROCESS_LABEL | فشل في ضبط لصيقة SMACK. انظر SmackProcessLabel= أعلاه.
237 | EXIT_KEYRING | فشل في إعداد حلقة مفاتيح النواة.
238 | EXIT_STATE_DIRECTORY | فشل في إعداد دليل حالة الوحدة. انظر StateDirectory= أعلاه.
239 | EXIT_CACHE_DIRECTORY | فشل في إعداد دليل خبيئة الوحدة. انظر CacheDirectory= أعلاه.
240 | EXIT_LOGS_DIRECTORY | فشل في إعداد دليل تسجيل الوحدة. انظر LogsDirectory= أعلاه.
241 | EXIT_CONFIGURATION_DIRECTORY | فشل في إعداد دليل ضبط الوحدة. انظر ConfigurationDirectory= أعلاه.
242 | EXIT_NUMA_POLICY | فشل في إعداد سياسة ذاكرة NUMA للوحدة. انظر NUMAPolicy= و NUMAMask= أعلاه.
243 | EXIT_CREDENTIALS | فشل في إعداد بيانات اعتماد الوحدة. انظر ImportCredential=، LoadCredential= و SetCredential= أعلاه.
245 | EXIT_BPF | فشل في تطبيق قيود BPF. انظر RestrictFileSystems= أعلاه.

أخيرًا، تُعرّف أنظمة تشغيل BSD مجموعة من رموز الخروج، وعادة ما تكون مُعرّفة على أنظمة لينكس أيضًا:

جدول 11. رموز خروج BSD
رمز الخروج | الاسم الرمزي | الوصف
64 | EX_USAGE | خطأ في استخدام سطر الأوامر
65 | EX_DATAERR | خطأ في تنسيق البيانات
66 | EX_NOINPUT | يتعذر فتح المدخلات
67 | EX_NOUSER | المُرسل إليه مجهول
68 | EX_NOHOST | اسم المضيف مجهول
69 | EX_UNAVAILABLE | الخدمة غير متاحة
70 | EX_SOFTWARE | خطأ داخلي في البرمجيات
71 | EX_OSERR | خطأ في النظام (مثلًا، يتعذر التفرع (fork))
72 | EX_OSFILE | ملف نظام تشغيل حرج مفقود
73 | EX_CANTCREAT | يتعذر إنشاء ملف مخرجات (المستخدم)
74 | EX_IOERR | خطأ في الإدخال/الإخراج
75 | EX_TEMPFAIL | فشل مؤقت؛ يُدعى المستخدم لإعادة المحاولة
76 | EX_PROTOCOL | خطأ عن بُعد في البروتوكول
77 | EX_NOPERM | رُفض الإذن
78 | EX_CONFIG | خطأ في الضبط

أمثلة

مثال 9. استخدام $MONITOR_*

خدمة myfailer.service التي يمكن أن تُشغِّل تبعية OnFailure=.

    [Unit]
    Description=Service which can trigger an OnFailure= dependency
    OnFailure=myhandler.service

    [Service]
    ExecStart=/bin/myprogram

خدمة mysuccess.service التي يمكن أن تُشغِّل تبعية OnSuccess=.

    [Unit]
    Description=Service which can trigger an OnSuccess= dependency
    OnSuccess=myhandler.service

    [Service]
    ExecStart=/bin/mysecondprogram

خدمة myhandler.service التي يمكن تشغيلها بواسطة أي من الخدمات أعلاه.

    [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"

إذا شُغِّلت الخدمة myfailer.service وأنهت عملها بفشل، فستُطلَق الخدمة myhandler.service وستُضبط متغيرات المراقبة كما يلي:

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

إذا شُغِّلت الخدمة mysuccess.service وأنهت عملها بنجاح، فستُطلَق الخدمة myhandler.service وستُضبط متغيرات المراقبة كما يلي:

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

انظر أيضًا

systemd(1)، systemctl(1)، systemd-analyze(1)، journalctl(1)، systemd-system.conf(5)، systemd.unit(5)، systemd.service(5)، systemd.socket(5)، systemd.swap(5)، systemd.mount(5)، systemd.kill(5)، systemd.resource-control(5)، systemd.time(7)، systemd.directives(7)، tmpfiles.d(5)، exec(3)، fork(2)

ملاحظات

1.  UAPI.2 مواصفات الأقسام القابلة للاكتشاف
    https://uapi-group.org/specifications/specs/discoverable_partitions_specification

2.  polkit
    https://www.freedesktop.org/software/polkit/docs/latest/

3.  نظام ملفات /proc
    https://docs.kernel.org/filesystems/proc.html#mount-options

4.  بناء جملة اسم المستخدم/المجموعة
    https://systemd.io/USER_NAMES

5.  وكيل كلمة المرور
    https://systemd.io/PASSWORD_AGENTS

6.  علم منع الامتيازات الجديدة
    https://docs.kernel.org/userspace-api/no_new_privs.html

7.  سجل مستخدم JSON
    https://systemd.io/USER_RECORD

8.  نظام ملفات /proc
    https://docs.kernel.org/filesystems/proc.html

9.  وصلات مُعينة الهوية (id-mapped mounts)
    https://lwn.net/Articles/896255/

10. quotactl
    https://man7.org/linux/man-pages/man2/quotactl.2.html

11. quotaon.
    https://linux.die.net/man/8/quotaon

12. repquota
    https://man7.org/linux/man-pages/man8/repquota.8.html

13. دمج صفحات النواة المتطابقة (Kernel Samepage Merging)
    https://docs.kernel.org/admin-guide/mm/ksm.html

14. دعم صفحات الذاكرة الضخمة الشفافة
    https://docs.kernel.org/admin-guide/mm/transhuge.html

15. منشور LWN
    https://lwn.net/Articles/947173/

16. قيم يونيكود القياسية
    https://www.unicode.org/glossary/#unicode_scalar_value

17. رموز يونيكود غير المحرفية
    https://www.unicode.org/glossary/#noncharacter

18. علامة ترتيب بايتات يونيكود
    https://www.unicode.org/glossary/#byte_order_mark

19. نص صدفة POSIX غير المقتبس
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01

20. نص صدفة POSIX المقتبس فرديًا
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02

21. نص صدفة POSIX المقتبس مزدوجًا
    https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03

22. Base64
    https://tools.ietf.org/html/rfc2045#section-6.8

23. واجهة الحاويات
    https://systemd.io/CONTAINER_INTERFACE

24. DMI/SMBIOS
    https://www.dmtf.org/standards/smbios

25. qemu
    https://www.qemu.org/docs/master/system/index.html

26. بيانات اعتماد النظام والخدمة
    https://systemd.io/CREDENTIALS

27. التعامل مع ضغط الموارد
    https://systemd.io/PRESSURE

28. مواصفات LSB
    https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.