محدودیت‌های منابع

به‌طور پیش‌فرض، sudoers از روش بومی سیستم‌عامل برای تنظیم محدودیت‌های منابع برای کاربر هدف استفاده می‌کند. در سیستم‌های لینوکس، محدودیت‌های منابع معمولاً توسط ماژول PAM به نام pam_limits.so تنظیم می‌شوند. در برخی از سیستم‌های BSD، پروندهٔ /etc/login.conf محدودیت‌های منابع را برای کاربر تعیین می‌کند. در سیستم‌های AIX، محدودیت‌های منابع در پروندهٔ /etc/security/limits پیکربندی می‌شوند. اگر مکانیزمی در سیستم برای تنظیم محدودیت‌های منابع به ازای هر کاربر وجود نداشته باشد، دستور با همان محدودیت‌های کاربر فراخواننده اجرا خواهد شد. تنها استثنا در این مورد، اندازهٔ پروندهٔ core dump است که توسط sudoers به‌طور پیش‌فرض روی 0 تنظیم شده است. غیرفعال‌سازی core dumpها به‌طور پیش‌فرض، امکان جلوگیری از مشکلات امنیتی احتمالی را فراهم می‌سازد که در آن‌ها با پروندهٔ core به عنوان ورودی قابل‌اعتماد برخورد می‌شود.

محدودیت‌های منابع همچنین می‌توانند در خود پروندهٔ sudoers تنظیم شوند، که در این حالت محدودیت‌های اعمال‌شده توسط سیستم را لغو می‌کنند. گزینه‌های rlimit_as, rlimit_core, rlimit_cpu, rlimit_data, rlimit_fsize, rlimit_locks, rlimit_memlock, rlimit_nofile, rlimit_nproc, rlimit_rss, rlimit_stack که در زیر شرح داده شده‌اند را ببینید. محدودیت‌های منابع در sudoers می‌توانند به یکی از قالب‌های زیر تعیین شوند:

“value”

هر دو محدودیت منابع نرم (soft) و سخت (hard) روی یک مقدار یکسان تنظیم می‌شوند. مقدار ویژهٔ “infinity” می‌تواند برای تعیین نامحدود بودن مقدار استفاده شود.

“soft,hard”

دو مقدار که با کاما از هم جدا شده‌اند. محدودیت نرم روی مقدار اول و محدودیت سخت روی مقدار دوم تنظیم می‌شود. هر دو مقدار باید درون یک جفت گیومهٔ دوگانه قرار گیرند، یا کاما باید با یک بک‌اسلش گریز داده شود (‘\’). مقدار ویژهٔ “infinity” می‌تواند به جای هر یک از این مقادیر استفاده شود.

“default”

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

“user”

محدودیت‌های منابع کاربر فراخواننده هنگام اجرای دستور حفظ خواهند شد.

به عنوان مثال، برای بازگرداندن رفتار تاریخی اندازهٔ پروندهٔ core dump، می‌توان از خطی مانند زیر استفاده کرد:

محدودیت‌های منابع در sudoers تنها در نسخهٔ 1.8.7 یا بالاتر پشتیبانی می‌شوند.

راهنمای فشرده EBNF

EBNF روشی فشرده و دقیق برای توصیف دستور زبان (گرامر) یک زبان است. هر تعریف EBNF از قواعد تولید. تشکیل شده است. برای نمونه:

symbol ::= definition | alternate1 | alternate2 ...

هر قاعدهٔ تولید به قواعد دیگر ارجاع می‌دهد و بدین ترتیب دستور زبان را برای زبان مورد نظر تشکیل می‌دهد. همچنین EBNF شامل عملگرهای زیر است که بسیاری از خوانندگان آن‌ها را از عبارت‌های باقاعده می‌شناسند. با این حال، نباید آن‌ها را با نویسه‌های “wildcard” اشتباه گرفت، چرا که دارای معانی متفاوتی هستند.

?

نشان می‌دهد که نماد (یا گروه نمادهای) قبلی اختیاری است. یعنی ممکن است یک بار ظاهر شود یا اصلاً ظاهر نشود.

*

نشان می‌دهد که نماد (یا گروه نمادهای) قبلی ممکن است صفر یا چند بار ظاهر شود.

+

نشان می‌دهد که نماد (یا گروه نمادهای) قبلی ممکن است یک یا چند بار ظاهر شود.

از پرانتز می‌توان برای گروه‌بندی نمادها با یکدیگر استفاده کرد. برای شفافیت، از نقل‌قول تکی ('') برای مشخص کردن یک رشته نویسه‌ای دقیق (در مقایسه با نام یک نماد) استفاده می‌شود.

نام‌های مستعار (Aliases)

چهار نوع نام مستعار وجود دارد: User_Alias, Runas_Alias, Host_Alias و Cmnd_Alias. با شروع از sudo 1.9.0، Cmd_Alias می‌تواند در صورت تمایل به جای Cmnd_Alias استفاده شود.

Alias ::= 'User_Alias'  User_Alias_Spec (':' User_Alias_Spec)* |
          'Runas_Alias' Runas_Alias_Spec (':' Runas_Alias_Spec)* |
          'Host_Alias'  Host_Alias_Spec (':' Host_Alias_Spec)* |
          'Cmnd_Alias'  Cmnd_Alias_Spec (':' Cmnd_Alias_Spec)* |
          'Cmd_Alias'   Cmnd_Alias_Spec (':' Cmnd_Alias_Spec)*

User_Alias ::= NAME

User_Alias_Spec ::= User_Alias '=' User_List

Runas_Alias ::= NAME

Runas_Alias_Spec ::= Runas_Alias '=' Runas_List

Host_Alias ::= NAME

Host_Alias_Spec ::= Host_Alias '=' Host_List

Cmnd_Alias ::= NAME

Cmnd_Alias_Spec ::= Cmnd_Alias '=' Cmnd_List

NAME ::= [A-Z]([A-Z][0-9]_)*

هر تعریف alias به شکل زیر است:

Alias_Type NAME = item1, item2, ...

که در آن Alias_Type یکی از User_Alias, Runas_Alias, Host_Alias, یا Cmnd_Alias. است. یک NAME رشته‌ای از حروف بزرگ لاتین، ارقام و نویسه‌های خط زیرین (‘_’). است. یک NAME باید با یک حرف بزرگ لاتین آغاز شود. امکان قرار دادن چندین تعریف نام مستعار از یک نوع در یک خط وجود دارد، متصل با دو نقطه (‘:’). برای نمونه:

Alias_Type NAME = item1, item2, item3 : NAME = item4, item5

تعریف مجدد یک alias موجود، خطای نحوی است. استفاده از نام یکسان برای aliases از انواع مختلف امکان‌پذیر است، اما توصیه نمی‌شود.

تعاریف آنچه که یک عضو معتبر alias را تشکیل می‌دهد در ادامه آمده است.

User_List ::= User |
              User ',' User_List

User ::= '!'* user name |
         '!'* #user-ID |
         '!'* %group |
         '!'* %#group-ID |
         '!'* +netgroup |
         '!'* %:nonunix_group |
         '!'* %:#nonunix_gid |
         '!'* User_Alias

یک User_List از یک یا چند نام کاربری، شناسه‌های کاربری (با پیشوند ‘#’), نام‌ها و شناسه‌های گروه سیستم (به‌ترتیب با پیشوند ‘%’ و ‘%#’ )، نت‌گروه‌ها (با پیشوند ‘+’), نام‌ها و شناسه‌های گروه غیر یونیکس (به‌ترتیب با پیشوند ‘%:’ و ‘%:#’ ) و User_Aliasها تشکیل شده است. هر مورد از فهرست می‌تواند صفر یا چند عملگر ‘!’ به عنوان پیشوند داشته باشد. تعداد فرد از عملگرهای ‘!’ مقدار مورد را نفی می‌کنند؛ تعداد زوج فقط یکدیگر را خنثی می‌کنند. تطبیق نت‌گروه‌های کاربری فقط با استفاده از اعضای user و domain انجام می‌شود؛ عضو host هنگام تطبیق استفاده نمی‌شود.

یک user name, user-ID, group, group-ID, netgroup, nonunix_group یا nonunix_gid می‌تواند داخل گیومه دوگانه قرار گیرد تا نیاز به گریزدهی نویسه‌های خاص برطرف شود. به‌علاوه، نویسه‌های خاص می‌توانند در حالت هگزادسیمال گریزدهی‌شده مشخص شوند، مانند \x20 برای فاصله. هنگام استفاده از گیومه دوگانه، هر نویسهٔ پیشوند باید درون گیومه قرار گیرد.

ساختار واقعی nonunix_group و nonunix_gid به افزایهٔ ارائه‌دهندهٔ گروه زیرین بستگی دارد. برای نمونه، افزایهٔ QAS AD از قالب‌های زیر پشتیبانی می‌کند:

• گروه در همان دامنه: "%:Group Name"
• گروه در هر دامنه‌ای: "%:Group Name@FULLY.QUALIFIED.DOMAIN"
• شناسهٔ SID گروه: "%:S-1-2-34-5678901234-5678901234-5678901234-567"

برای اطلاعات بیشتر GROUP PROVIDER PLUGINS را ببینید.

قراردادن نام‌های گروه در نقل‌قول اختیاری است. رشته‌های بدون نقل‌قول باید از بک‌اسلش (‘\’) برای گریز دادن فاصله‌ها و نویسه‌های خاص استفاده کنند. برای فهرستی از نویسه‌هایی که باید گریز داده شوند Other special characters and reserved words را ببینید.

Runas_List ::= Runas_Member |
               Runas_Member ',' Runas_List

Runas_Member ::= '!'* user name |
                 '!'* #user-ID |
                 '!'* %group |
                 '!'* %#group-ID |
                 '!'* %:nonunix_group |
                 '!'* %:#nonunix_gid |
                 '!'* +netgroup |
                 '!'* Runas_Alias |
                 '!'* ALL

یک Runas_List مشابه یک User_List است با این تفاوت که به جای User_Aliasها می‌تواند شامل Runas_Aliasها باشد. نام‌های کاربری و گروه‌ها به عنوان رشته تطبیق داده می‌شوند. به عبارت دیگر، دو کاربر (یا گروه) با شناسهٔ کاربری (یا شناسهٔ گروه) یکسان متمایز در نظر گرفته می‌شوند. اگر می‌خواهید تمام نام‌های کاربری با شناسهٔ کاربری یکسان (مانند root و toor) را تطبیق دهید، می‌توانید به جای نام از شناسهٔ کاربری استفاده کنید (#0 در مثال ارائه‌شده). شناسهٔ کاربری یا شناسهٔ گروه مشخص‌شده در یک Runas_Member نیازی به فهرست شدن در پایگاه دادهٔ گذرواژه‌ها یا گروه‌ها ندارد.

Host_List ::= Host |
              Host ',' Host_List

Host ::= '!'* host name |
         '!'* ip_addr |
         '!'* network(/netmask)? |
         '!'* +netgroup |
         '!'* Host_Alias |
         '!'* ALL

یک Host_List از یک یا چند نام میزبان، نشانی IP، شماره شبکه، netgroupها (با پیشوند ‘+) ،’ و سایر نام‌های مستعار تشکیل شده است. مجدداً، مقدار یک مورد می‌تواند با عملگر ‘!’ نفی شود. تطبیق netgroupهای میزبان تنها با استفاده از اعضای میزبان (هم کامل و هم نامحدود) و دامنه انجام می‌شود؛ عضو کاربر در تطبیق به کار نمی‌رود. اگر شماره شبکه را بدون netmask مشخص کنید، sudo هر یک از رابط‌های شبکه میزبان محلی را بررسی کرده و اگر شماره شبکه با یکی از رابط‌های شبکه میزبان مطابقت داشته باشد، از netmask آن رابط استفاده خواهد کرد. می‌توان netmask را با نمادگذاری استاندارد نشانی IP (مانند 255.255.255.0 یا ffff:ffff:ffff:ffff::)، یا نمادگذاری CIDR (تعداد بیت‌ها، مانند 24 یا 64) مشخص کرد. نام میزبان می‌تواند شامل نویسه‌های عام به سبک پوسته باشد (بخش Wildcards در زیر را ببینید)، اما مگر اینکه دستور hostname روی سیستم شما نام کامل میزبان را برگرداند، نیاز است از پرچم fqdn استفاده کنید تا نویسه‌های عام قابل استفاده باشند. sudo تنها رابط‌های شبکه واقعی را بررسی می‌کند؛ این یعنی نشانی IP 127.0.0.1 (localhost) هرگز مطابقت نخواهد داشت. همچنین، نام میزبان “localhost” تنها در صورتی مطابقت داده می‌شود که نام واقعی میزبان باشد، که معمولاً تنها برای سیستم‌های جدا از شبکه صادق است.

digest ::= [A-Fa-f0-9]+ |
           [A-Za-z0-9\+/=]+

Digest_Spec ::= "sha224" ':' digest |
                "sha256" ':' digest |
                "sha384" ':' digest |
                "sha512" ':' digest

Digest_List ::= Digest_Spec |
                Digest_Spec ',' Digest_List

Cmnd_List ::= Cmnd |
              Cmnd ',' Cmnd_List

command name ::= regex |
                 file name

command ::= command name |
            command name args |
            command name regex |
            command name '""' |
            ALL

Edit_Spec ::= "sudoedit" file name+ |
              "sudoedit" regex |
              "sudoedit"

List_Spec ::= "list"

Cmnd ::= Digest_List? '!'* command |
         '!'* directory |
         '!'* Edit_Spec |
         '!'* List_Spec |
         '!'* Cmnd_Alias

یک Cmnd_List فهرستی از یک یا چند دستور، دایرکتوری یا نام مستعار است. یک دستور، نام کامل فایل است که می‌تواند شامل جانشین‌های سبک پوسته باشد (بخش Wildcards زیر را ببینید)، یا عبارت باقاعده‌ای که با ‘^’ شروع شده و با ‘$’ پایان می‌یابد (بخش Regular expressions زیر را ببینید). یک دایرکتوری، نام مسیر کاملی است که به ‘/’. ختم می‌شود. هنگامی که یک دایرکتوری را در Cmnd_List, مشخص می‌کنید، کاربر قادر خواهد بود هر فایلی را درون آن دایرکتوری اجرا کند (اما نه در هیچ‌یک از زیردایرکتوری‌های آن). اگر هیچ آرگومان خط فرمانی مشخص نشده باشد، کاربر می‌تواند دستور را با هر آرگومان دلخواهی اجرا کند. آرگومان‌های خط فرمان می‌توانند شامل جانشین‌ها یا یک عبارت باقاعده باشند که با ‘^’ آغاز شده و با ‘$’. پایان می‌یابد. اگر آرگومان‌های خط فرمان شامل ‘""’, باشند، دستور تنها می‌تواند بدون هیچ آرگومانی اجرا شود.

اگر یک Cmnd دارای آرگومان‌های خط فرمان مرتبط باشد، آرگومان‌های موجود در Cmnd باید با موارد ارائه‌شده توسط کاربر در خط فرمان مطابقت داشته باشند. اگر آرگومان‌ها در یک Cmnd با نویسهٔ ‘^’ آغاز شوند، به عنوان عبارت باقاعده تفسیر شده و بر همان اساس تطبیق داده می‌شوند. در غیر این صورت، هنگام تطبیق از جانشین‌های سبک پوسته استفاده می‌شود. مگر در صورت تعیین عبارت باقاعده، نویسه‌های زیر در صورت استفاده در آرگومان‌های دستور باید با یک ‘\’ گریز داده شوند: ‘,’, ‘:’, ‘=’, ‘\’. برای جلوگیری از اینکه آرگومان‌های درون یک Cmnd که با نویسهٔ ‘^’ شروع می‌شوند به عنوان عبارت باقاعده تفسیر شوند، نویسهٔ ‘^’ باید با یک ‘\’. گریز داده شود.

دو دستور توکار درون خودِ sudo وجود دارند: “list” و “sudoedit”. برخلاف سایر دستورها، این دو باید در پروندهٔ sudoers به صورت بدون مسیر ابتدایی مشخص شوند.

دستور توکار “list” می‌تواند برای مجاز ساختن کاربر جهت فهرست کردن امتیازات کاربری دیگر با گزینهٔ sudo's -U استفاده شود. برای نمونه، “sudo -l -U otheruser”. کاربری با امتیاز “list” قادر است امتیازات کاربر دیگری را فهرست کند حتی اگر مجوزی برای اجرای دستورها به عنوان آن کاربر نداشته باشد. به‌طور پیش‌فرض، تنها root یا کاربری با توانایی اجرای هر دستوری به عنوان root یا user مشخص‌شده روی میزبان فعلی می‌تواند از گزینهٔ -U استفاده کند. هیچ آرگومان خط فرمانی نباید همراه با دستور توکار “list” مشخص شود.

دستور توکار “sudoedit” برای اجازه دادن به کاربر جهت اجرای sudo با گزینهٔ -e (یا به عنوان sudoedit) به کار می‌رود. این دستور می‌تواند درست مانند یک دستور معمولی، آرگومان‌های خط فرمان بپذیرد. برخلاف سایر دستورها، “sudoedit” در درون خود sudo تعبیه شده است و باید در پروندهٔ sudoers بدون مسیر ابتدایی مشخص شود. اگر مسیر ابتدایی وجود داشته باشد، برای نمونه /usr/bin/sudoedit ، نام مسیر بدون اعلان خطا به “sudoedit” تبدیل می‌شود. یک مسیر کامل برای sudoedit توسط visudo به عنوان خطا در نظر گرفته می‌شود.

یک command می‌تواند با یک Digest_List پیشوند شود؛ فهرستی از یک یا چند مدخل Digest_Spec که با کاما از هم جدا شده‌اند. اگر یک Digest_List وجود داشته باشد، دستور تنها در صورتی با موفقیت مطابقت داده می‌شود که بتوان آن را با استفاده از یکی از خلاصه پیام‌های SHA-2 در فهرست تأیید کرد. از نسخهٔ 1.9.0، کلمهٔ کلیدی ALL می‌تواند در ترکیب با یک Digest_List استفاده شود. قالب‌های خلاصهٔ زیر پشتیبانی می‌شوند: sha224، sha256، sha384 و sha512. رشته می‌تواند در قالب hex یا base64 مشخص شود (base64 فشرده‌تر است). چندین ابزار کمکی قادر به تولید خلاصه پیام‌های SHA-2 در قالب hex هستند مانند openssl، shasum، sha224sum، sha256sum، sha384sum، sha512sum.

برای نمونه، با استفاده از openssl:

$ openssl dgst -sha224 /bin/ls
SHA224(/bin/ls)= 118187da8364d490b4a7debbf483004e8f3e053ec954309de2c41a25

همچنین می‌توان از openssl برای تولید خروجی base64 استفاده کرد:

$ openssl dgst -binary -sha224 /bin/ls | openssl base64
EYGH2oNk1JC0p9679IMATo8+BT7JVDCd4sQaJQ==

هشدار: اگر کاربر دسترسی نوشتن به خود دستور را داشته باشد (مستقیم یا از طریق یک دستور sudo )، ممکن است کاربر بتواند پس از بررسی خلاصه پیام اما پیش از اجرای دستور، آن را جایگزین کند. شرایط رقابتی مشابهی در سیستم‌های فاقد فراخوان سیستمی fexecve(2) وجود دارد، در صورتی که دایرکتوری حاوی دستور توسط کاربر قابل نوشتن باشد. برای اطلاعات بیشتر در مورد نحوهٔ اجرای دستورهای دارای خلاصه توسط sudo ، توضیحات مربوط به تنظیم fdexec را ببینید.

خلاصه پیام‌های دستور تنها در نسخهٔ 1.8.7 یا بالاتر پشتیبانی می‌شوند.

پیش‌فرض‌ها (Defaults)

برخی گزینه‌های پیکربندی ممکن است در زمان اجرا از مقادیر پیش‌فرض خود از طریق یک یا چند خط Default_Entry تغییر یابند. این موارد می‌توانند بر همهٔ کاربران در هر میزبانی، همهٔ کاربران در یک میزبان خاص، یک کاربر خاص، یک دستور خاص یا دستورهایی که تحت عنوان کاربری خاص اجرا می‌شوند اثر بگذارند. ورودی‌های به ازای دستور نباید شامل آرگومان‌های خط فرمان باشند. اگر نیاز به تعیین آرگومان دارید، یک Cmnd_Alias تعریف کرده و به جای آن به همان ارجاع دهید.

Default_Type ::= 'Defaults' |
                 'Defaults' '@' Host_List |
                 'Defaults' ':' User_List |
                 'Defaults' '!' Cmnd_List |
                 'Defaults' '>' Runas_List

Default_Entry ::= Default_Type Parameter_List

Parameter_List ::= Parameter |
                   Parameter ',' Parameter_List

Parameter ::= Parameter '=' Value |
              Parameter '+=' Value |
              Parameter '-=' Value |
              '!'* Parameter

پارامترها می‌توانند flags ، مقادیر integer ، strings ، یا lists باشند. پرچم‌ها به‌صورت ضمنی بولی هستند و می‌توان آن‌ها را از طریق عملگر ‘!’ غیرفعال کرد. برخی پارامترهای عددی، رشته‌ای و فهرستی نیز ممکن است در یک زمینهٔ بولی برای غیرفعال کردنشان به کار روند. مقادیر در صورتی که شامل چند کلمه باشند می‌توانند درون نقل‌قول جفتی ("") قرار گیرند. نویسه‌های خاص را می‌توان با یک بک‌اسلش (‘\’) گریز داد.

برای گنجاندن یک نویسهٔ بک‌اسلش دقیق در یک آرگومان خط فرمان، باید بک‌اسلش را دوبار گریز دهید. برای نمونه، برای تطابق با ‘\n’ به‌عنوان بخشی از یک آرگومان خط فرمان، باید از ‘\\\\n’ در پروندهٔ sudoers استفاده کنید. این به دلیل وجود دو سطح از گریز است، یکی در خود تجزیه‌گر sudoers و دیگری هنگامی که آرگومان‌های خط فرمان توسط تابع fnmatch(3) یا regexec(3) مطابقت داده می‌شوند.

فهرست‌ها دارای دو عملگر انتساب اضافی هستند: ‘+=’ و ‘-=’. این عملگرها به ترتیب برای افزودن به فهرست و حذف از آن استفاده می‌شوند. استفاده از عملگر ‘-=’ برای حذف عنصری که در فهرست وجود ندارد خطا محسوب نمی‌شود.

ورودی‌های Defaults به ترتیب زیر تجزیه می‌شوند: ابتدا پیش‌فرض‌های سراسری، میزبان، کاربر و runas، سپس پیش‌فرض‌های دستور. اگر چندین تنظیم Defaults از یک نوع وجود داشته باشد، آخرین تنظیم منطبق استفاده می‌شود. تنظیمات Defaults زیر پیش از سایر موارد تجزیه می‌شوند زیرا ممکن است بر ورودی‌های بعدی اثر بگذارند: fqdn, group_plugin, runas_default, sudoers_locale.

برای فهرستی از پارامترهای پشتیبانی‌شدهٔ Defaults، بخش SUDOERS OPTIONS را ببینید.

مشخصات کاربر (User specification)

User_Spec ::= User_List Host_List '=' Cmnd_Spec_List \
              (':' Host_List '=' Cmnd_Spec_List)*

Cmnd_Spec_List ::= Cmnd_Spec |
                   Cmnd_Spec ',' Cmnd_Spec_List

Cmnd_Spec ::= Runas_Spec? Option_Spec* (Tag_Spec ':')* Cmnd

Runas_Spec ::= '(' Runas_List? (':' Runas_List)? ')'

Option_Spec ::= (SELinux_Spec | Date_Spec | Timeout_Spec | Chdir_Spec | Chroot_Spec)

SELinux_Spec ::= ('ROLE=role' | 'TYPE=type')

Date_Spec ::= ('NOTBEFORE=timestamp' | 'NOTAFTER=timestamp')

Timeout_Spec ::= 'TIMEOUT=timeout'

Chdir_Spec ::= 'CWD=directory'

Chroot_Spec ::= 'CHROOT=directory'

Tag_Spec ::= ('EXEC' | 'NOEXEC' | 'FOLLOW' | 'NOFOLLOW' |
              'LOG_INPUT' | 'NOLOG_INPUT' | 'LOG_OUTPUT' |
              'NOLOG_OUTPUT' | 'MAIL' | 'NOMAIL' | 'INTERCEPT' |
              'NOINTERCEPT' | 'PASSWD' | 'NOPASSWD' | 'SETENV' |
              'NOSETENV')

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

ساختار اصلی مشخصات کاربر به این صورت است: “who where = (as_whom) what”. اجزای تشکیل‌دهنده آن در ادامه بررسی می‌شود:

مشخصات Runas (Runas_Spec)

یک Runas_Spec کاربر و/یا گروهی را که یک دستور می‌تواند تحت عنوان آن اجرا شود، مشخص می‌کند. یک Runas_Spec کامل شامل دو Runas_List (همان‌طور که در بالا تعریف شد) است که با یک دونقطه (‘:’) از هم جدا شده و درون یک جفت پرانتز قرار گرفته‌اند. نخستین Runas_List مشخص می‌کند دستور از طریق گزینهٔ -u تحت عنوان چه کاربرانی می‌تواند اجرا شود. دومین فهرست، گروه‌هایی را تعریف می‌کند که می‌توانند از طریق گزینهٔ -g مشخص شوند (علاوه بر هر یک از گروه‌های متعلق به کاربر هدف). اگر هر دو Runas_List تعیین شده باشند، دستور می‌تواند با هر ترکیبی از کاربران و گروه‌های فهرست‌شده در Runas_List های مربوطه‌شان اجرا شود. اگر تنها مورد نخست مشخص شده باشد، دستور می‌تواند تحت عنوان هر کاربری در فهرست و به‌صورت اختیاری با هر گروهی که کاربر هدف عضو آن است، اجرا گردد. اگر نخستین Runas_List خالی باشد اما دومی مشخص شده باشد، دستور می‌تواند تحت عنوان کاربر فراخواننده همراه با گروهی از فهرست Runas_List اجرا شود. اگر هر دو Runas_List خالی باشند، دستور تنها می‌تواند تحت عنوان کاربر فراخواننده اجرا شود و گروه نیز در صورت تعیین، باید از گروه‌هایی باشد که کاربر فراخواننده عضو آن است. اگر هیچ Runas_Spec مشخص نشده باشد، دستور تنها می‌تواند تحت عنوان کاربر runas_default (root به‌صورت پیش‌فرض) اجرا شود و گروه نیز، در صورت تعیین، باید از گروه‌هایی باشد که کاربر runas_default عضو آن است.

یک Runas_Spec مقدار پیش‌فرض را برای دستورهای پس از خود تعیین می‌کند. بدین معنا که برای مدخل:

dgb	boulder = (operator) /bin/ls, /bin/kill, /usr/bin/lprm

کاربر dgb می‌تواند /bin/ls, /bin/kill, و /usr/bin/lprm را روی میزبان boulder—اما فقط تحت عنوان operator اجرا کند. برای نمونه:

$ sudo -u operator /bin/ls

همچنین امکان بازنویسی یک Runas_Spec در ادامهٔ یک مدخل وجود دارد. اگر مدخل را بدین‌صورت تغییر دهیم:

dgb	boulder = (operator) /bin/ls, (root) /bin/kill, /usr/bin/lprm

اکنون کاربر dgb مجاز است /bin/ls را تحت عنوان operator, اما /bin/kill و /usr/bin/lprm را تحت عنوان root اجرا کند.

می‌توان این را گسترش داد تا به dgb اجازه اجرای /bin/ls با قرار دادن هر یک از کاربر یا گروه روی operator: داده شود:

dgb	boulder = (operator : operator) /bin/ls, (root) /bin/kill,\
	/usr/bin/lprm

در حالی که بخش گروه در Runas_Spec به کاربر اجازه می‌دهد تا دستور را با آن گروه اجرا کند، اما کاربر را مجبور به انجام این کار نمی‌کند. اگر هیچ گروهی در خط فرمان مشخص نشود، دستور با گروه فهرست‌شده در مدخل پایگاه داده گذرواژه کاربر مقصد اجرا خواهد شد. موارد زیر همگی توسط مدخل sudoers بالا مجاز خواهند بود:

$ sudo -u operator /bin/ls
$ sudo -u operator -g operator /bin/ls
$ sudo -g operator /bin/ls

در مثال زیر، کاربر tcm می‌تواند دستوراتی را اجرا کند که با گروه dialer به یک پرونده دستگاه مودم دسترسی دارند.

tcm	boulder = (:dialer) /usr/bin/tip, /usr/bin/cu,\
	/usr/local/bin/minicom

در این مثال تنها گروه تنظیم خواهد شد و اجرای دستور همچنان با کاربر tcm. است. برای مثال:

$ sudo -g dialer /usr/bin/cu

ممکن است چندین کاربر و گروه در یک Runas_Spec, حضور داشته باشند، که در این صورت کاربر می‌تواند هر ترکیبی از کاربران و گروه‌ها را با گزینه‌های -u و -g انتخاب کند. در این مثال:

alan	ALL = (root, bin : operator, system) ALL

کاربر alan می‌تواند هر دستوری را به عنوان کاربر root یا bin, با امکان تعیین اختیاری گروه روی operator یا system اجرا کند.

مشخصات گزینه‌ها (Option_Spec)

یک Cmnd می‌تواند صفر یا چند گزینه مرتبط با خود داشته باشد. گزینه‌ها می‌توانند شامل نقش‌ها و/یا انواع SELinux، تاریخ‌های شروع و/یا پایان و مهلت‌های زمانی دستور باشند. زمانی که یک گزینه برای یک Cmnd, تنظیم شود، Cmnd‌های بعدی در Cmnd_Spec_List, آن گزینه را به ارث می‌برند مگر اینکه توسط گزینه دیگری جایگزین شوند. نام گزینه‌ها کلمات رزروشده در sudoers. هستند. این بدان معناست که هیچ‌یک از نام‌های معتبر گزینه‌ها (پایین را ببینید) نمی‌توانند هنگام تعریف یک نام مستعار (alias) استفاده شوند.

مشخصات SELinux (SELinux_Spec)

در سیستم‌های دارای پشتیبانی از SELinux، مدخل‌های پرونده‌ی sudoers می‌توانند به‌صورت اختیاری یک نقش و/یا نوع SELinux مرتبط با یک دستور داشته باشند. این ویژگی می‌تواند برای پیاده‌سازی نوعی از کنترل دسترسی بر پایه نقش (RBAC) استفاده شود. اگر یک نقش یا نوع به همراه دستور مشخص شود، مقادیر پیش‌فرض تعیین‌شده در sudoers. را بازنویسی می‌کند. با این حال، یک نقش یا نوع مشخص‌شده در خط فرمان، بر مقادیر موجود در sudoers اولویت خواهد داشت.

مشخصات تاریخ (Date_Spec)

قوانین sudoers را می‌توان با یک تاریخ شروع و پایان از طریق تنظیمات NOTBEFORE و NOTAFTER مشخص کرد. برچسب زمانی باید در قالب “Generalized Time” همان‌طور که در RFC 4517 تعریف شده است، مشخص شود. قالب در عمل به‌صورت ‘yyyymmddHHMMSSZ’ است که در آن دقیقه و ثانیه اختیاری هستند. پسوند ‘Z’ نشان می‌دهد که برچسب زمانی در ساعت هماهنگ جهانی (UTC) است. همچنین می‌توان به‌جای ‘Z ،’ اختلاف منطقه زمانی از UTC را بر حسب ساعت و دقیقه مشخص کرد. به‌عنوان مثال، ‘-0500’ معادل زمان استاندارد شرقی در ایالات متحده خواهد بود. به‌عنوان یک قابلیت توسعه‌یافته، اگر هیچ ‘Z’ یا اختلاف منطقه زمانی مشخص نشده باشد، زمان محلی استفاده خواهد شد.

موارد زیر همگی برچسب‌های زمانی معتبر هستند:

20170214083000Z
2017021408Z
20160315220000-0500
20151201235900

مشخصات مهلت زمانی (Timeout_Spec)

یک دستور ممکن است دارای یک مهلت زمانی مرتبط باشد. اگر مهلت زمانی پیش از پایان اجرای دستور منقضی شود، دستور خاتمه داده خواهد شد. مهلت زمانی را می‌توان در ترکیب‌هایی از روز، ساعت، دقیقه و ثانیه همراه با یک پسوند تک‌حرفیِ غیرحساس به حروف بزرگ و کوچک که واحد زمان را مشخص می‌کند، تعیین کرد. به‌عنوان مثال، مهلت زمانیِ ۷ روز، ۸ ساعت، ۳۰ دقیقه و ۱۰ ثانیه به‌صورت ‘7d8h30m10s’ نوشته می‌شود. اگر عددی بدون واحد مشخص شود، ثانیه در نظر گرفته می‌شود. هر یک از واحدهای روز، ساعت، دقیقه یا ثانیه را می‌توان نادیده گرفت. ترتیب واحدها باید از بزرگ‌ترین به کوچک‌ترین باشد و یک واحد نباید بیش از یک بار مشخص شود.

موارد زیر همگی مقادیر مهلت زمانیِ معتبر هستند: ‘7d8h30m10s’, ‘14d’, ‘8h30m’, ‘600s’, ‘3600’. موارد زیر مقادیر مهلت زمانیِ نامعتبر هستند: ‘12m2w1d’, ‘30s10m4h’, ‘1d2d3h’.

این تنظیم فقط در نگارش 1.8.20 یا بالاتر پشتیبانی می‌شود.

مشخصات دایرکتوری کاری (Chdir_Spec)

دایرکتوری کاری که دستور در آن اجرا خواهد شد را می‌توان با استفاده از تنظیم CWD مشخص کرد. directory باید یک نام مسیر کامل باشد که با نویسه ‘/’ یا ‘~’ یا مقدار ویژه “*”. آغاز شود. مقدار “*” نشان می‌دهد که کاربر می‌تواند دایرکتوری کاری را با اجرای sudo همراه با گزینه -D مشخص کند. به‌طور پیش‌فرض، دستورها از دایرکتوری کاری فعلی کاربر فراخواننده اجرا می‌شوند، مگر اینکه گزینه -i داده شده باشد. نام‌های مسیر به شکل ~user/path/name به‌صورت نسبی نسبت به دایرکتوری خانگی کاربرِ نام‌برده تفسیر می‌شوند. اگر نام کاربر حذف شود، مسیر نسبت به دایرکتوری خانگی کاربر runas خواهد بود.

این تنظیم فقط در نسخه 1.9.3 یا بالاتر پشتیبانی می‌شود.

مشخصات Chroot (Chroot_Spec)

دایرکتوری ریشه‌ای که دستور در آن اجرا خواهد شد را می‌توان با استفاده از تنظیم CHROOT مشخص کرد. directory باید یک نام مسیر کامل باشد که با نویسه ‘/’ یا ‘~’ یا مقدار ویژه “*”. آغاز شود. مقدار “*” نشان می‌دهد که کاربر می‌تواند دایرکتوری ریشه را با اجرای sudo همراه با گزینه -R مشخص کند. این تنظیم می‌تواند برای اجرای دستور در یک chroot(2) “sandbox” مشابه ابزار chroot(8) استفاده شود. نام‌های مسیر به شکل ~user/path/name به‌صورت نسبی نسبت به دایرکتوری خانگی کاربرِ نام‌برده تفسیر می‌شوند. اگر نام کاربر حذف شود، مسیر نسبت به دایرکتوری خانگی کاربر runas خواهد بود.

این تنظیم فقط در نسخه 1.9.3 یا بالاتر پشتیبانی می‌شود.

مشخصات برچسب (Tag_Spec)

یک دستور می‌تواند صفر یا چند برچسب مرتبط با خود داشته باشد. مقادیر برچسب زیر پشتیبانی می‌شوند: EXEC, NOEXEC, FOLLOW, NOFOLLOW, LOG_INPUT, NOLOG_INPUT, LOG_OUTPUT, NOLOG_OUTPUT, MAIL, NOMAIL, INTERCEPT, NOINTERCEPT, PASSWD, NOPASSWD, SETENV, و NOSETENV. هنگامی که برچسبی روی یک Cmnd, تنظیم شود، Cmnds بعدی در Cmnd_Spec_List, آن برچسب را به ارث می‌برند مگر اینکه توسط برچسب مخالف بازنویسی شود (به عبارت دیگر، PASSWD جایگزین NOPASSWD و NOEXEC جایگزین EXEC).

EXEC و NOEXEC

اگر sudo با پشتیبانی از noexec کامپایل شده باشد و سیستم‌عامل زیرین نیز از آن پشتیبانی کند، برچسب NOEXEC می‌تواند برای جلوگیری از اجرای دستورهای دیگر توسط یک فایل اجرایی با پیوند پویا استفاده شود.

در مثال زیر، کاربر aaron می‌تواند /usr/bin/more و /usr/bin/vi را اجرا کند اما فرار به پوسته غیرفعال خواهد بود.

aaron	shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

برای جزئیات بیشتر دربارهٔ نحوهٔ کارکرد NOEXEC و اینکه آیا روی سیستم شما کار خواهد کرد یا خیر، بخش Preventing shell escapes در ادامه را ببینید.

FOLLOW و NOFOLLOW

از نسخهٔ 1.8.15 به بعد، sudoedit فایلی را که پیوند نمادین باشد باز نخواهد کرد مگر اینکه پرچم sudoedit_follow فعال شده باشد. برچسب‌های FOLLOW و NOFOLLOW مقدار sudoedit_follow را لغو می‌کنند و می‌توان از آن‌ها برای مجاز (یا ممنوع) کردن ویرایش پیوندهای نمادین به‌ازای هر دستور استفاده کرد. این برچسب‌ها فقط برای دستور sudoedit مؤثرند و برای تمام دستورهای دیگر نادیده گرفته می‌شوند.

LOG_INPUT و NOLOG_INPUT

این برچسب‌ها مقدار پرچم log_input را به‌ازای هر دستور لغو می‌کنند. برای اطلاعات بیشتر، بخش I/O LOGGING را ببینید.

LOG_OUTPUT و NOLOG_OUTPUT

این برچسب‌ها مقدار پرچم log_output را به‌ازای هر دستور لغو می‌کنند. برای اطلاعات بیشتر، بخش I/O LOGGING را ببینید.

MAIL و NOMAIL

این برچسب‌ها با لغو کردن مقدار پرچم mail_all_cmnds به‌ازای هر دستور، کنترل دقیقی روی ارسال ایمیل هنگام اجرای یک دستور توسط کاربر فراهم می‌کنند. آن‌ها زمانی که sudo با گزینه‌های -l یا -v اجرا شود، هیچ اثری ندارند. یک برچسب NOMAIL همچنین گزینه‌های mail_always و mail_no_perms را لغو خواهد کرد. برای اطلاعات بیشتر، توضیحات mail_all_cmnds, mail_always, و mail_no_perms در بخش SUDOERS OPTIONS در ادامه را ببینید.

PASSWD و NOPASSWD

به‌طور پیش‌فرض، sudo نیاز دارد که کاربر پیش از اجرای یک دستور، احراز هویت کند. این رفتار را می‌توان از طریق برچسب NOPASSWD تغییر داد. مانند یک Runas_Spec, برچسب NOPASSWD یک مقدار پیش‌فرض برای دستورهایی که پس از آن در Cmnd_Spec_List. می‌آیند تعیین می‌کند. در مقابل، می‌توان از برچسب PASSWD برای بازگرداندن این رفتار استفاده کرد. برای نمونه:

ray	rushmore = NOPASSWD: /bin/kill, /bin/ls, /usr/bin/lprm

به کاربر ray اجازه می‌دهد تا /bin/kill, /bin/ls, و /usr/bin/lprm را به عنوان root روی ماشین “rushmore” بدون نیاز به احراز هویت اجرا کند. اگر فقط بخواهیم ray بتواند /bin/kill را بدون گذرواژه اجرا کند، ورودی به شکل زیر خواهد بود:

ray	rushmore = NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm

با این حال، توجه داشته باشید که برچسب PASSWD هیچ تاثیری بر کاربرانی که در گروه مشخص‌شده توسط تنظیمات exempt_group قرار دارند، ندارد.

به‌طور پیش‌فرض، اگر برچسب NOPASSWD برای هر یک از ورودی‌های کاربر در میزبان فعلی اعمال شده باشد، کاربر می‌تواند ‘sudo -l’ را بدون گذرواژه اجرا کند. علاوه بر این، کاربر تنها در صورتی می‌تواند ‘sudo -v’ را بدون گذرواژه اجرا کند که تمام ورودی‌های کاربر برای میزبان فعلی دارای برچسب NOPASSWD باشند. این رفتار را می‌توان از طریق گزینه‌های verifypw و listpw بازنویسی کرد.

SETENV و NOSETENV

این برچسب‌ها مقدار پرچم setenv را به ازای هر دستور بازنویسی می‌کنند. اگر SETENV برای دستوری تنظیم شده باشد، کاربر می‌تواند پرچم env_reset را از خط فرمان از طریق گزینهٔ -E غیرفعال کند. علاوه بر این، متغیرهای محیطیِ مقداردهی‌شده در خط فرمان مشمول محدودیت‌های اعمال‌شده توسط env_check, env_delete, یا env_keep. نمی‌شوند. به این ترتیب، تنها کاربران مورد اعتماد باید مجاز به تعیین متغیرها به این شیوه باشند. اگر دستور مطابقت‌یافته ALL, باشد، برچسب SETENV به‌صورت ضمنی برای آن دستور اعمال می‌شود؛ این حالت پیش‌فرض را می‌توان با استفاده از برچسب NOSETENV بازنویسی کرد.

INTERCEPT و NOINTERCEPT

اگر sudo با پشتیبانی از intercept کامپایل شده باشد و سیستم‌عامل زیربنایی از آن پشتیبانی کند، برچسب INTERCEPT می‌تواند برای اعتبارسنجی برنامه‌های ایجادشده توسط یک فرمان در برابر sudoers و ثبت لاگ آن‌ها، دقیقاً مانند زمانی که مستقیماً از طریق sudo اجرا می‌شوند، استفاده شود. این قابلیت همراه با دستورهایی که اجازه فرار به شل را می‌دهند مانند ویرایشگرها، شل‌ها و صفحه‌بندها مفید است. به‌دلیل بررسی سیاست‌ها سربار اضافی وجود دارد که ممکن است هنگام اجرای فرمان‌هایی مانند اسکریپت‌های شل که تعداد زیادی زیرفرمان اجرا می‌کنند، تاخیر ایجاد کند. برای فرمان‌های تعاملی، مانند یک شل یا ویرایشگر، این سربار معمولاً محسوس نیست.

در مثال زیر، کاربر chuck می‌تواند هر فرمانی را روی دستگاه “research” در حالت intercept اجرا کند.

chuck	research = INTERCEPT: ALL

برای جزئیات بیشتر در مورد نحوه کارکرد INTERCEPT و اینکه آیا روی سیستم شما کار خواهد کرد یا خیر، بخش Preventing shell escapes را در ادامه ببینید.

نویسه‌های عام (Wildcards)

sudo اجازه می‌دهد از wildcards سبک شل (معروف به نویسه‌های meta یا glob) در نام میزبان‌ها، مسیرها و آرگومان‌های خط فرمان در پرونده sudoers استفاده شود. تطبیق نویسه‌های عام از طریق توابع glob(3) و fnmatch(3) همان‌طور که در IEEE Std 1003.1 (“POSIX.1”) مشخص شده است انجام می‌شود.

*

با هر مجموعه‌ای از صفر یا چند نویسه (شامل فاصله) مطابقت دارد.

?

با هر تک‌نویسه (شامل فاصله) مطابقت دارد.

[...]

با هر نویسه‌ای در محدوده مشخص‌شده مطابقت دارد.

[!...]

با هر نویسه‌ای که در محدوده مشخص‌شده نیست مطابقت دارد.

\x

برای هر نویسه ‘x ،’ به ‘x’ ارزیابی می‌شود. این برای گریز دادن نویسه‌های خاص استفاده می‌شود، مانند: ‘* ،’ ‘? ،’ ‘[ ،’ و ‘]’.

کلاس‌های نویسه در صورتی قابل استفاده هستند که توابع glob(3) و fnmatch(3) سیستم شما از آن‌ها پشتیبانی کنند. با این حال، از آنجا که نویسه ‘:’ معنای خاصی در sudoers دارد، باید گریز داده شود. برای مثال:

/bin/ls [[\:alpha\:]]*

با هر نام پرونده‌ای که با یک حرف شروع شود مطابقت خواهد داشت.

یک ممیز رو به جلو (‘/’) توسط نویسه‌های عامِ استفاده‌شده در بخش نام پرونده در دستور، مطابقت داده نخواهد شد. این امر برای آن است که مسیری مانند:

/usr/bin/*

با /usr/bin/who مطابقت داشته باشد، اما با /usr/bin/X11/xterm مطابقت نداشته باشد.

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

استثناهای قوانین نویسه‌های عام

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

""

اگر رشته خالیِ ‘""’ تنها آرگومان خط فرمان در مدخل پرونده sudoers باشد، به این معنی است که اجرای دستور با هیچ آرگومانی مجاز نیست.

sudoedit

آرگومان‌های خط فرمان برای دستور توکارِ sudoedit باید همیشه نام مسیر باشند؛ بنابراین ممیز رو به جلو (‘/’) با نویسه عام مطابقت داده نخواهد شد.

عبارت‌های منظم (Regular expressions)

از نسخه 1.9.10 به بعد، امکان استفاده از عبارت‌های منظم برای نام مسیرها و آرگومان‌های خط فرمان وجود دارد. عبارت‌های منظم نسبت به wildcards سبک پوسته قابلیت بیانگری بیشتری دارند و معمولاً ایمن‌تر هستند زیرا هنگام مطابقت، درجه کنترل بیشتری فراهم می‌کنند. نوع عبارت‌های منظم پشتیبانی‌شده توسط sudoers از نوع عبارت‌های منظم توسعه‌یافته POSIX است، مشابه آنچه توسط ابزار egrep(1) استفاده می‌شود. این موارد معمولاً بر اساس سیستم، در کتابچه‌های راهنمای regex(7) یا re_format(7) مستندسازی شده‌اند. به عنوان یک قابلیت توسعه‌یافته، اگر عبارت منظم با “(?i)” آغاز شود، مطابقت بدون حساسیت به حروف بزرگ و کوچک انجام خواهد شد.

در sudoers ، عبارت‌های منظم باید با نویسه ‘^’ شروع شوند و با نویسه ‘$’ به پایان برسند. این امر مشخص می‌کند چه مواردی عبارت منظم هستند و چه مواردی نیستند. نام مسیر، آرگومان‌های خط فرمان یا هر دو می‌توانند عبارت منظم باشند. از آنجا که نام مسیر و آرگومان‌ها به صورت مجزا مطابقت داده می‌شوند، حتی امکان استفاده از نویسه‌های عام برای نام مسیر و عبارت‌های منظم برای آرگومان‌ها وجود دارد. امکان استفاده از یک عبارت منظم واحد برای مطابقت هم‌زمان دستور و آرگومان‌های آن وجود ندارد. طول عبارت‌های منظم در sudoers به ۱۰۲۴ نویسه محدود است.

هیچ نیازی به گریز دادن نویسه‌های خاص sudoers در یک عبارت منظم وجود ندارد، به جز علامت پوند (‘#’).

در مثال زیر، کاربر john می‌تواند دستور passwd(1) را با هویت root روی هر میزبانی اجرا کند، ولی مجاز به تغییر گذرواژهٔ root نیست. بیان امن این نوع قاعده با استفاده از نویسه‌های عمومی (wildcards) ناممکن است.

john	ALL = /usr/bin/passwd ^[a-zA-Z0-9_]+$,\
              !/usr/bin/passwd root

همچنین امکان استفاده از عبارات باقاعده در ترکیب با قواعد sudoedit وجود دارد. قاعدهٔ زیر به کاربر bob تنها امکان ویرایش پرونده‌های /etc/motd, /etc/issue, و /etc/hosts را می‌دهد.

bob    ALL = sudoedit ^/etc/(motd|issue|hosts)$

عبارات باقاعده همچنین می‌توانند برای تطبیق خود دستور استفاده شوند. در این مثال، از یک عبارت باقاعده استفاده شده است تا به کاربر sid اجازهٔ اجرای دستورهای /usr/sbin/groupadd, /usr/sbin/groupmod, /usr/sbin/groupdel, /usr/sbin/useradd, /usr/sbin/usermod, و /usr/sbin/userdel با هویت root داده شود.

sid    ALL = ^/usr/sbin/(group|user)(add|mod|del)$

یک عیب استفاده از عبارت باقاعده برای تطبیق نام دستور، عدم امکان تطبیق مسیرهای نسبی مانند ./useradd یا ../sbin/useradd است. این موضوع هنگام استفاده از عبارت باقاعده برای نام دستور همراه با عملگر نقیض، ‘!’, تبعات امنیتی دارد، زیرا چنین قواعدی را می‌توان به سادگی دور زد. به همین دلیل، استفاده از عبارت باقاعدهٔ منفی‌شده برای نام دستور به شدت نهی می‌شود. این موضوع شامل دستورهای منفی‌شده‌ای که تنها از عبارت باقاعده برای تطبیق آرگومان‌های دستور استفاده می‌کنند، نمی‌شود. برای اطلاعات بیشتر، بخش Regular expressions in command names در ادامه را ببینید.

فراخوانی پرونده‌های دیگر از درون sudoers

امکان فراخوانی دیگر پرونده‌های sudoers از درون پروندهٔ sudoers فعلی در حال پردازش، با استفاده از دستورالعمل‌های @include و @includedir وجود دارد. جهت سازگاری با نگارش‌های sudo پیش از 1.9.1، #include و #includedir نیز پذیرفته می‌شوند.

یک پروندهٔ include می‌تواند برای نمونه جهت نگهداری یک پروندهٔ sudoers سراسری در کنار یک پروندهٔ محلی مخصوص هر ماشین استفاده شود. برای این مثال، پروندهٔ sudoers سراسری /etc/sudoers و پروندهٔ مخصوص هر ماشین /etc/sudoers.local خواهد بود. برای فراخوانی /etc/sudoers.local از درون /etc/sudoers می‌توان از خط زیر در /etc/sudoers: استفاده کرد:

@include /etc/sudoers.local

هنگامی که sudo به این خط می‌رسد، پردازش پروندهٔ کنونی (/etc/sudoers) را متوقف کرده و به /etc/sudoers.local. تغییر وضعیت می‌دهد. پس از رسیدن به انتهای /etc/sudoers.local ، باقی‌ماندهٔ /etc/sudoers پردازش خواهد شد. پرونده‌های فراخوانی‌شده می‌توانند خود پرونده‌های دیگری را فراخوانی کنند. یک محدودیت سخت ۱۲۸ سطحی برای پرونده‌های تودرتو اعمال می‌شود تا از ایجاد حلقه‌های فراخوانی پرونده جلوگیری شود.

از نسخهٔ 1.9.1 به بعد، مسیر پروندهٔ فراخوانی‌شده در صورت گریز با بک‌اسلش (‘\’). می‌تواند شامل فاصله باشد. همچنین می‌توان تمام مسیر را درون جفت‌نقل‌قول قرار داد ("" ،) که در این صورت نیازی به گریز دادن نیست. برای گنجاندن خود نویسهٔ بک‌اسلش در مسیر، باید از ‘\\’ استفاده شود.

اگر مسیر پروندهٔ فراخوانی‌شده کامل نباشد (با ‘/’) آغاز نشود)، باید در همان شاخه‌ای قرار داشته باشد که پروندهٔ sudoers اصلی از آن فراخوانی شده است. برای نمونه اگر /etc/sudoers شامل این خط باشد:

@include sudoers.local

پرونده‌ای که فراخوانی خواهد شد /etc/sudoers.local. است.

نام پرونده همچنین می‌تواند شامل گریز ‘%h’ باشد که نمایانگر شکل کوتاه نام میزبان است. به عبارت دیگر، اگر نام میزبان دستگاه “xerxes” باشد، آنگاه

@include /etc/sudoers.%h

باعث خواهد شد که sudo پروندهٔ /etc/sudoers.xerxes. را فراخوانی کند.

دستورالعمل @includedir می‌تواند برای ایجاد یک شاخهٔ sudoers.d به کار رود تا مدیر بستهٔ سیستم بتواند هنگام نصب بسته‌ها، قوانین پروندهٔ sudoers را در آن قرار دهد. برای نمونه با داشتن:

@includedir /etc/sudoers.d

sudo پردازش پروندهٔ کنونی را متوقف کرده و تمام پرونده‌های موجود در /etc/sudoers.d ، را می‌خواند؛ در حالی که برای جلوگیری از ایجاد مشکل با پرونده‌های موقت یا پشتیبان ویرایشگر و مدیر بسته، از پرونده‌هایی که به ‘~’ ختم می‌شوند یا دارای نویسهٔ ‘.’ هستند صرف‌نظر می‌کند.

پرونده‌ها به ترتیب لغوی مرتب و تجزیه می‌شوند. یعنی /etc/sudoers.d/01_first پیش از /etc/sudoers.d/10_second. تجزیه خواهد شد. توجه داشته باشید به دلیل اینکه مرتب‌سازی لغوی است و نه عددی، /etc/sudoers.d/1_whoops پس از /etc/sudoers.d/10_second. بارگذاری خواهد شد. استفاده از تعداد صفرهای پیشرو یکسان در نام پرونده‌ها می‌تواند برای جلوگیری از چنین مشکلاتی به کار رود. پس از تجزیهٔ پرونده‌های درون شاخه، کنترل به پرونده‌ای بازمی‌گردد که شامل دستورالعمل @includedir بوده است.

بر خلاف پرونده‌های گنجانده‌شده از طریق @include, ابزار visudo پرونده‌های درون پوشهٔ @includedir را ویرایش نخواهد کرد، مگر اینکه یکی از آن‌ها دارای خطای نگارشی باشد. همچنان اجرای visudo با پرچم -f برای ویرایش مستقیم پرونده‌ها ممکن است، اما این کار مانع تعریف مجدد یک alias که در پروندهٔ دیگری نیز وجود دارد نخواهد شد.

سایر نویسه‌های ویژه و کلمات رزروشده

علامت هش (‘#’) برای نشان دادن توضیح به کار می‌رود (مگر اینکه بخشی از دستورالعمل #include باشد یا در زمینهٔ نام کاربری قرار گرفته و با یک یا چند رقم دنبال شود، که در این حالت به عنوان یک شناسهٔ کاربری در نظر گرفته می‌شود). هم نویسهٔ توضیح و هم هر متنی پس از آن، تا انتهای خط، نادیده گرفته می‌شوند.

کلمهٔ رزروشدهٔ ALL یک alias توکار است که همواره باعث موفقیت در تطبیق می‌شود. می‌توان از آن در هر جایی که در حالت معمول از یک Cmnd_Alias, User_Alias, Runas_Alias, یا Host_Alias. استفاده می‌شود، بهره برد. تلاش برای تعریف یک alias با نام ALL منجر به خطای نگارشی خواهد شد. استفاده از ALL می‌تواند خطرناک باشد زیرا در زمینهٔ دستور، به کاربر اجازهٔ اجرای هر دستوری را روی سامانه می‌دهد.

نام گزینه‌های زیر که در یک Option_Spec مجاز هستند نیز کلمات رزروشده در نظر گرفته می‌شوند: CHROOT, ROLE, TYPE, TIMEOUT, CWD, NOTBEFORE و NOTAFTER. تلاش برای تعریف یک alias هم‌نام با یکی از این گزینه‌ها، منجر به خطای نگارشی خواهد شد.

علامت تعجب (‘!’) می‌تواند به عنوان عملگر منطقی not در یک فهرست یا alias و همچنین در ابتدای یک Cmnd. به کار رود. این ویژگی امکان مستثنی کردن مقادیر مشخصی را فراهم می‌کند. برای موثر بودن عملگر ‘!’ باید چیزی وجود داشته باشد تا توسط آن مستثنی شود. برای مثال، جهت تطبیق همهٔ کاربران به جز root می‌توان از این الگو استفاده کرد:

ALL, !root

اگر ALL, حذف شود، مانند:

!root

این عبارت صراحتاً root را رد می‌کند اما با هیچ کاربر دیگری تطبیق نخواهد یافت. این رفتار با یک عملگر واقعی “negation” متفاوت است.

با این حال، توجه داشته باشید که استفاده از ‘!’ همراه با نام مستعار توکار ALL برای مجاز ساختن کاربر به اجرای “همه به‌جز چند” دستور به‌ندرت طبق انتظار عمل می‌کند (بخش SECURITY NOTES در زیر را ببینید).

خطوط طولانی می‌توانند با یک بک‌اسلش (‘\’) به عنوان آخرین نویسه خط ادامه یابند.

فاصله‌های خالی بین عناصر در یک فهرست و همچنین نویسه‌های نحوی خاص در یک User Specification (‘=’, ‘:’, ‘(’, ‘)’) اختیاری هستند.

نویسه‌های زیر باید با یک بک‌اسلش (‘\’) گریز داده شوند هنگامی که به عنوان بخشی از یک کلمه به کار می‌روند (مانند نام کاربری یا نام میزبان): ‘!’, ‘=’, ‘:’, ‘,’, ‘(’, ‘)’, ‘\’. رفتار sudo را می‌توان همان‌طور که پیش‌تر توضیح داده شد، با خطوط Default_Entry تغییر داد. فهرستی از تمام پارامترهای پشتیبانی‌شدهٔ Defaults که بر اساس نوع گروه‌بندی شده‌اند، در زیر آمده است.

پرچم‌های بولی:

always_query_group_plugin

اگر یک group_plugin پیکربندی شده باشد، از آن برای حل گروه‌هایی به فرم ‘%group’ استفاده می‌شود، تا زمانی که گروه سیستمی هم‌نامی وجود نداشته باشد. به‌طور معمول، فقط گروه‌هایی به فرم ‘%:group’ به group_plugin ارسال می‌شوند. این پرچم به‌طور پیش‌فرض off است.

always_set_home

در صورت فعال بودن، sudo متغیر محیطی HOME را روی پوشهٔ خانگی کاربر هدف تنظیم می‌کند (که همان کاربر runas_default است، مگر اینکه از گزینهٔ -u استفاده شده باشد). این پرچم تا حد زیادی منسوخ شده است و هیچ اثری ندارد مگر اینکه پرچم env_reset غیرفعال شده باشد یا HOME در فهرست env_keep وجود داشته باشد، که انجام هر دوی آن‌ها اکیداً نهی شده است. این پرچم به‌طور پیش‌فرض off است.

authenticate

در صورت تنظیم، کاربران باید قبل از اجرای دستورها با گذرواژه (یا روش‌های دیگر احراز هویت) خود را احراز هویت کنند. این مقدار پیش‌فرض را می‌توان از طریق برچسب‌های PASSWD و NOPASSWD بازنویسی کرد. این پرچم به‌طور پیش‌فرض on است.

case_insensitive_group

در صورت فعال بودن، نام گروه‌ها در sudoers بدون حساسیت به بزرگی و کوچکی حروف مطابقت داده می‌شوند. این مورد ممکن است هنگامی که کاربران در LDAP یا AD ذخیره شده‌اند لازم باشد. این پرچم به‌طور پیش‌فرض on است.

case_insensitive_user

در صورت فعال بودن، نام کاربران در sudoers بدون حساسیت به بزرگی و کوچکی حروف مطابقت داده می‌شوند. این مورد ممکن است هنگامی که گروه‌ها در LDAP یا AD ذخیره شده‌اند لازم باشد. این پرچم به‌طور پیش‌فرض on است.

closefrom_override

در صورت تنظیم، کاربر می‌تواند از گزینهٔ -C استفاده کند که نقطهٔ شروع پیش‌فرضی را که sudo از آنجا شروع به بستن توصیف‌کننده‌های باز پرونده می‌کند بازنویسی می‌نماید. این پرچم به‌طور پیش‌فرض off است.

compress_io

در صورت تنظیم، و اگر sudo برای ثبت ورودی یا خروجی یک دستور پیکربندی شده باشد، گزارش‌های I/O با استفاده از zlib فشرده خواهند شد. این پرچم به‌طور پیش‌فرض در صورتی که sudo با پشتیبانی از zlib کامپایل شده باشد on است.

exec_background

به‌طور پیش‌فرض، sudo تا زمانی که خود sudo در پیش‌زمینه در حال اجرا باشد، دستور را به عنوان یک فرایند پیش‌زمینه اجرا می‌کند. هنگامی که پرچم exec_background فعال باشد و دستور در یک شبه‌ترمینال اجرا شود (به دلیل ثبت وقایع I/O یا پرچم use_pty )، دستور به عنوان یک فرایند پس‌زمینه اجرا خواهد شد. تلاش برای خواندن از ترمینال کنترل‌کننده (یا تغییر تنظیمات ترمینال) به معلق شدن دستور با سیگنال SIGTTIN (یا سیگنال SIGTTOU در صورت تغییر تنظیمات ترمینال) منجر می‌شود. اگر این اتفاق زمانی رخ دهد که sudo یک فرایند پیش‌زمینه است، ترمینال کنترل‌کننده به دستور واگذار شده و بدون نیاز به دخالت کاربر در پیش‌زمینه از سر گرفته می‌شود. مزیت اجرای اولیه دستور در پس‌زمینه این است که sudo نیازی به خواندن از ترمینال ندارد مگر اینکه دستور صریحاً آن را درخواست کند. در غیر این صورت، هر ورودی ترمینال باید به دستور منتقل شود، چه به آن نیاز داشته باشد چه نداشته باشد (هسته ترمینال‌ها را بافر می‌کند، بنابراین تشخیص اینکه آیا دستور واقعاً ورودی را می‌خواهد یا خیر ممکن نیست). این رفتار با رفتار پیشین sudo یا زمانی که دستور در شبه‌ترمینال اجرا نمی‌شود متفاوت است.

برای کارکرد بی‌نقص این قابلیت، سیستم‌عامل باید از راه‌اندازی مجدد خودکار فراخوان‌های سیستمی پشتیبانی کند. متأسفانه همه سیستم‌عامل‌ها به‌طور پیش‌فرض این کار را انجام نمی‌دهند، و حتی مواردی که پشتیبانی می‌کنند نیز ممکن است باگ داشته باشند. برای نمونه، macOS در راه‌اندازی مجدد توابع tcgetattr(3) و tcsetattr(3) ناموفق است (این یک باگ در macOS است). علاوه بر این، از آنجا که این رفتار به متوقف شدن دستور با سیگنال‌های SIGTTIN یا SIGTTOU وابسته است، برنامه‌هایی که این سیگنال‌ها را دریافت کرده و خود را با سیگنال دیگری (معمولاً SIGTOP) معلق می‌کنند، به‌طور خودکار به پیش‌زمینه آورده نخواهند شد. برخی از نسخه‌های دستور su(1) در لینوکس بدین صورت عمل می‌کنند. این پرچم به‌طور پیش‌فرض off است.

این تنظیم فقط در نسخه 1.8.7 یا بالاتر پشتیبانی می‌شود. هیچ تأثیری ندارد مگر اینکه ثبت وقایع I/O فعال باشد یا پرچم use_pty فعال شده باشد.

env_editor

در صورت تنظیم، visudo پیش از رجوع به فهرست ویرایشگرهای پیش‌فرض، از مقدار متغیرهای محیطی SUDO_EDITOR, VISUAL یا EDITOR استفاده خواهد کرد. visudo معمولاً با دسترسی root اجرا می‌شود، بنابراین این پرچم ممکن است به کاربری با دسترسی‌های visudo اجازه دهد تا دستورهای دلخواه را بدون ثبت در گزارش به‌عنوان root اجرا کند. راهکار جایگزین، قرار دادن فهرستی از ویرایشگرهای “safe” جداشده با دونقطه در تنظیم editor است. سپس visudo تنها در صورتی از SUDO_EDITOR, VISUAL یا EDITOR استفاده خواهد کرد که با مقداری مشخص‌شده در editor مطابقت داشته باشند. اگر پرچم env_reset فعال باشد، متغیرهای محیطی SUDO_EDITOR, VISUAL و/یا EDITOR باید در فهرست env_keep حضور داشته باشند تا هنگام فراخوانی visudo از طریق sudo ، پرچم env_editor عمل کند. این پرچم به‌طور پیش‌فرض on است.

env_reset

در صورت تنظیم، sudo دستور را در محیطی حداقلی شامل متغیرهای TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER و SUDO_* اجرا خواهد کرد. سپس هر متغیری در محیط فراخواننده یا پروندهٔ مشخص‌شده با تنظیم restricted_env_file که با فهرست‌های env_keep و env_check همخوانی داشته باشد اضافه می‌شود، و در ادامه متغیرهای موجود در پروندهٔ مشخص‌شده با تنظیم env_file (در صورت وجود) افزوده خواهند شد. محتوای فهرست‌های env_keep و env_check پس از اعمال تغییرات پارامترهای سراسری Defaults در sudoers ، هنگام اجرای sudo توسط root با گزینهٔ -V نمایش داده می‌شود. اگر تنظیم secure_path فعال باشد، مقدار آن برای متغیر محیطی PATH استفاده خواهد شد. این پرچم به‌طور پیش‌فرض on است.

fast_glob

در حالت عادی، sudo از تابع glob(3) برای تطبیق الگو به سبک پوسته (globbing) هنگام بررسی نام مسیرها استفاده می‌کند. اما از آنجا که این تابع به سیستم پرونده دسترسی دارد، تکمیل glob(3) برای برخی الگوها ممکن است زمان زیادی طول بکشد، به‌ویژه زمانی که الگو به یک سیستم پروندهٔ شبکه‌ای اشاره دارد که بر حسب تقاضا سوار (auto mounted) شده است. پرچم fast_glob باعث می‌شود sudo از تابع fnmatch(3) استفاده کند که برای انجام تطبیق خود به سیستم پرونده دسترسی پیدا نمی‌کند. نقطه ضعف fast_glob این است که توانایی تطبیق مسیرهای نسبی مانند ./ls یا ../bin/ls. را ندارد. این موضوع زمانی که نام‌های مسیر دارای نویسه‌های تطبیق الگو همراه با عملگر نقیض، ‘!’, به کار می‌روند، پیامدهای امنیتی دارد، زیرا چنین قوانینی به سادگی قابل دور زدن هستند. بنابراین، این پرچم نباید زمانی استفاده شود که پروندهٔ sudoers شامل قوانینی با مسیرهای منفی‌شده دارای نویسه‌های تطبیق الگو باشد. این پرچم به‌طور پیش‌فرض off است.

log_passwords

بیشتر برنامه‌هایی که به گذرواژهٔ کاربر نیاز دارند، پیش از خواندن گذرواژه بازتاب (echo) را غیرفعال می‌کنند تا از نمایش گذرواژه به صورت متن آشکار روی صفحه جلوگیری شود. با این حال، اگر ورودی ترمینال در حال لاگ شدن باشد (ببینید: I/O LOGGING), گذرواژه همچنان در لاگ I/O حضور خواهد داشت. اگر گزینهٔ log_passwords غیرفعال باشد، sudoers تلاش می‌کند از ثبت گذرواژه‌ها در لاگ جلوگیری کند. این کار با استفاده از عبارات باقاعده در passprompt_regex برای تطبیق اعلان (prompt) گذرواژه در بافر خروجی ترمینال انجام می‌شود. هنگام یافتن تطابق، نویسه‌های ورودی در لاگ I/O با ‘*’ جایگزین می‌شوند تا زمانی که یک خط جدید (line feed) یا بازگشت به سر خط (carriage return) در ورودی ترمینال یافت شود یا بافر خروجی ترمینال جدیدی دریافت گردد. اما اگر برنامه‌ای نویسه‌ها را هم‌زمان با تایپ کاربر نمایش دهد (مانند sudo زمانی که pwfeedback تنظیم شده است)، تنها نویسهٔ نخست گذرواژه در لاگ I/O جایگزین خواهد شد. این گزینه هیچ اثری ندارد مگر اینکه log_input یا log_ttyin نیز تنظیم شده باشند. این پرچم به‌طور پیش‌فرض on است.

این تنظیم فقط در نسخهٔ 1.9.10 یا بالاتر پشتیبانی می‌شود.

fqdn

این پرچم را زمانی تنظیم کنید که می‌خواهید نام‌های کاملاً معین میزبان (FQDN) را در پروندهٔ sudoers قرار دهید، در حالی که نام میزبان محلی (برگردانده شده توسط دستور ‘hostname’ ) شامل نام دامنه نباشد. به عبارت دیگر، به جای myhost از myhost.mydomain.edu استفاده خواهید کرد. در صورت تمایل همچنان می‌توانید از قالب کوتاه استفاده کنید (و حتی هر دو را با هم ترکیب کنید). این پرچم تنها زمانی مؤثر است که نام میزبان “canonical” برگردانده شده توسط تابع getaddrinfo(3) یا gethostbyname(3) یک نام دامنهٔ کاملاً معین (FQDN) باشد. این وضعیت معمولاً زمانی برقرار است که سیستم برای تفکیک نام میزبان از DNS استفاده کند.

اگر سامانه طوری پیکربندی شده باشد که از پروندهٔ /etc/hosts به‌جای DNS استفاده کند، ممکن است نام میزبان “canonical” کاملاً واجد شرایط (fully-qualified) نباشد. ترتیب پرس‌وجو از منابع برای تحلیل نام میزبان معمولاً در پرونده‌های /etc/nsswitch.conf, /etc/netsvc.conf, /etc/host.conf, یا در برخی موارد /etc/resolv.conf مشخص می‌شود. در پروندهٔ /etc/hosts نخستین نام میزبان در مدخل، نام “canonical” در نظر گرفته می‌شود؛ نام‌های بعدی نام‌های مستعاری هستند که توسط sudoers استفاده نمی‌شوند. برای نمونه، خط زیر در پروندهٔ hosts برای ماشین “xyzzy” نام دامنهٔ کاملاً واجد شرایط را به عنوان نام میزبان “canonical” و نسخهٔ کوتاه را به عنوان نام مستعار دارد.

192.168.1.1 xyzzy.sudo.ws xyzzy

اگر مدخل پروندهٔ hosts ماشین به درستی قالب‌بندی نشده باشد، پرچم fqdn در صورتی که پیش از DNS پرس‌وجو شود، کارساز نخواهد بود.

توجه داشته باشید هنگام استفاده از DNS برای تحلیل نام میزبان، فعال کردن fqdn نیازمند این است که sudoers پرس‌وجوهای DNS انجام دهد که در صورت از کار افتادن DNS (برای نمونه در صورت قطع اتصال ماشین از شبکه)، sudo را غیرقابل‌استفاده می‌کند. دقیقاً مانند پروندهٔ hosts، باید از نام “canonical” همان‌گونه که DNS آن را می‌شناسد استفاده کنید. به این معنی که به دلیل مسائل کارایی و عدم امکان دریافت تمام نام‌های مستعار از DNS، نباید از نام مستعار میزبان (مدخل CNAME) استفاده شود.

این پرچم به‌طور پیش‌فرض on است.

ignore_audit_errors

اجازه به اجرای دستورها حتی اگر sudoers نتواند در گزارش بازرسی (audit log) بنویسد. در صورت فعال بودن، خطای نوشتن در گزارش بازرسی به عنوان خطای مهلک تلقی نمی‌شود. در صورت غیرفعال بودن، دستور تنها پس از ثبت موفقیت‌آمیز رویداد بازرسی می‌تواند اجرا شود. این پرچم تنها روی سامانه‌هایی مؤثر است که در آن‌ها sudoers از ثبت رویدادهای بازرسی پشتیبانی می‌کند، از جمله FreeBSD, Linux، macOS و Solaris. این پرچم به‌طور پیش‌فرض on است.

ignore_dot

در صورت تنظیم، sudo از "." یا "" (هر دو نشان‌دهندهٔ دایرکتوری جاری هستند) در متغیر محیطی PATH چشم‌پوشی می‌کند؛ خود PATH تغییری نمی‌کند. این پرچم به‌طور پیش‌فرض off است.

ignore_iolog_errors

اجازه به اجرای دستورها حتی اگر sudoers نتواند در گزارش I/O (محلی یا دوردست) بنویسد. در صورت فعال بودن، خطای نوشتن در گزارش I/O به عنوان خطای مهلک تلقی نمی‌شود. در صورت غیرفعال بودن، چنانچه نوشتن در گزارش I/O انجام نشود، دستور خاتمه می‌یابد. این پرچم به‌طور پیش‌فرض off است.

ignore_logfile_errors

اجازه به اجرای دستورها حتی اگر sudoers نتواند در پروندهٔ گزارش بنویسد. در صورت فعال بودن، خطای نوشتن در پروندهٔ گزارش به عنوان خطای مهلک تلقی نمی‌شود. در صورت غیرفعال بودن، دستور تنها پس از ثبت موفقیت‌آمیز مدخل در پروندهٔ گزارش می‌تواند اجرا شود. این پرچم تنها زمانی تأثیر دارد که sudoers برای استفاده از گزارش‌گیری مبتنی بر پرونده از طریق تنظیم logfile پیکربندی شده باشد. این پرچم به‌طور پیش‌فرض on است.

ignore_local_sudoers

اگر از طریق LDAP تنظیم شود، تجزیهٔ /etc/sudoers نادیده گرفته خواهد شد. این گزینه برای سامانه‌هایی در نظر گرفته شده که می‌خواهند از استفاده از پرونده‌های محلی sudoers جلوگیری کنند تا تنها از LDAP استفاده شود. این کار تلاش‌های گردانندگان سرکش را که قصد افزودن نقش‌ها به /etc/sudoers. دارند خنثی می‌کند. هنگامی که این پرچم فعال باشد، /etc/sudoers حتی نیازی به وجود داشتن ندارد. از آنجا که این پرچم به sudo می‌گوید در صورت عدم تطابق با مدخل‌های خاص LDAP چگونه رفتار کند، این sudoOption تنها برای بخش ‘cn=defaults’ معنادار است. این پرچم به‌طور پیش‌فرض off است.

ignore_unknown_defaults

در صورت تنظیم، sudo در صورت مواجهه با یک مدخل ناشناختهٔ Defaults در پروندهٔ sudoers یا یک sudoOption ناشناخته در LDAP، هشداری صادر نخواهد کرد. این پرچم به‌طور پیش‌فرض off است.

insults

در صورت تنظیم، sudo هنگام وارد کردن گذرواژه نادرست، به کاربران توهین خواهد کرد. این پرچم به‌طور پیش‌فرض off است.

log_allowed

در صورت تنظیم، sudoers دستورهای مجاز توسط خط‌مشی را در گزارش بازرسی سیستم (در صورت پشتیبانی) و همچنین در syslog و/یا یک پرونده گزارش ثبت می‌کند. این پرچم به‌طور پیش‌فرض on است.

این تنظیم فقط در نگارش 1.8.29 یا بالاتر پشتیبانی می‌شود.

log_denied

در صورت تنظیم، sudoers دستورهای رد شده توسط خط‌مشی را در گزارش بازرسی سیستم (در صورت پشتیبانی) و همچنین در syslog و/یا یک پرونده گزارش ثبت می‌کند. این پرچم به‌طور پیش‌فرض on است.

این تنظیم فقط در نگارش 1.8.29 یا بالاتر پشتیبانی می‌شود.

log_exit_status

در صورت تنظیم، sudoers مقدار وضعیت خروج دستورهای اجرا شده را در syslog و/یا یک پرونده گزارش ثبت خواهد کرد. اگر دستوری با یک سیگنال خاتمه یابد، نام سیگنال نیز ثبت می‌شود. این پرچم به‌طور پیش‌فرض off است.

این تنظیم فقط در نگارش 1.9.8 یا بالاتر پشتیبانی می‌شود.

log_host

در صورت تنظیم، نام میزبان در مدخل‌های گزارش نوشته‌شده در پروندهٔ پیکربندی‌شده توسط تنظیم logfile گنجانده خواهد شد. این پرچم به‌طور پیش‌فرض off است.

log_input

در صورت تنظیم، sudo دستور را در یک شبه‌ترمینال اجرا می‌کند (اگر sudo از یک ترمینال اجرا شده باشد) و تمام ورودی کاربر را ثبت خواهد کرد. اگر ورودی استاندارد به دلیل هدایت مجدد I/O یا قرار داشتن دستور در یک خط لوله، به ترمینال کاربر متصل نباشد، آن ورودی نیز ثبت می‌شود. برای اطلاعات بیشتر دربارهٔ ثبت I/O، بخش I/O LOGGING را ببینید. این پرچم به‌طور پیش‌فرض off است.

log_output

در صورت تنظیم، sudo دستور را در یک شبه‌ترمینال (در صورتی که sudo از یک ترمینال اجرا شده باشد) اجرا کرده و تمام خروجی ارسال‌شده به ترمینال کاربر، خروجی استاندارد یا خطای استاندارد را ثبت می‌کند. اگر خروجی استاندارد یا خطای استاندارد به دلیل تغییر مسیر I/O یا به این دلیل که دستور بخشی از یک خط‌لوله (pipeline) است به ترمینال کاربر متصل نباشد، آن خروجی نیز ثبت می‌شود. برای اطلاعات بیشتر درباره ثبت I/O، بخش I/O LOGGING را ببینید. این پرچم به طور پیش‌فرض off است.

log_server_keepalive

در صورت تنظیم، sudo گزینه سوکت TCP keepalive را در اتصال به سرور لاگ فعال می‌کند. این کار ارسال دوره‌ای پیام‌های keepalive به سرور را امکان‌پذیر می‌سازد. اگر سرور به پیامی پاسخ ندهد، اتصال بسته خواهد شد و دستور در حال اجرا خاتمه می‌یابد، مگر اینکه پرچم ignore_iolog_errors (در صورت فعال بودن ثبت I/O) یا پرچم ignore_log_errors (در صورت غیرفعال بودن ثبت I/O) تنظیم شده باشد. این پرچم به طور پیش‌فرض on است.

این تنظیم فقط در نسخه 1.9.0 یا بالاتر پشتیبانی می‌شود.

log_server_verify

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

این تنظیم فقط در نسخه 1.9.0 یا بالاتر پشتیبانی می‌شود.

log_stderr

در صورت تنظیم، sudo خطای استاندارد را در صورتی که به ترمینال کاربر متصل نباشد ثبت می‌کند. این گزینه می‌تواند برای ثبت خروجی هدایت‌شده به یک لوله (pipe) یا تغییر مسیر یافته به یک فایل استفاده شود. این پرچم به طور پیش‌فرض off است، اما در صورتی که پرچم log_output یا برچسب دستور LOG_OUTPUT تنظیم شده باشد، فعال می‌شود.

log_stdin

در صورت تنظیم، sudo ورودی استاندارد را در صورتی که به ترمینال کاربر متصل نباشد ثبت می‌کند. این گزینه می‌تواند برای ثبت ورودی ارسالی از یک لوله (pipe) یا تغییر مسیر یافته از یک فایل استفاده شود. این پرچم به طور پیش‌فرض off است، اما در صورتی که پرچم log_input یا برچسب دستور LOG_INPUT تنظیم شده باشد، فعال می‌شود.

log_stdout

در صورت تنظیم، sudo خروجی استاندارد را در صورتی که به ترمینال کاربر متصل نباشد ثبت می‌کند. این گزینه می‌تواند برای ثبت خروجی هدایت‌شده به یک لوله (pipe) یا تغییر مسیر یافته به یک فایل استفاده شود. این پرچم به طور پیش‌فرض off است، اما در صورتی که پرچم log_output یا برچسب دستور LOG_OUTPUT تنظیم شده باشد، فعال می‌شود.

log_subcmds

در صورت تنظیم، sudoers هنگامی که یک دستور یک فرایند فرزند ایجاد می‌کند و برنامه‌ای را با استفاده از توابع کتابخانه‌ای execve(2), execl(3), execle(3), execlp(3), execv(3), execvp(3), execvpe(3), یا system(3) اجرا می‌نماید، آن را ثبت می‌کند. به عنوان مثال، اگر یک پوسته توسط sudo اجرا شود، دستورات مجزایی که از طریق آن پوسته اجرا می‌شوند ثبت خواهند شد. این پرچم به طور پیش‌فرض off است.

پرچم log_subcmds از همان سازوکار پایه‌ای تنظیم intercept استفاده می‌کند. برای اطلاعات بیشتر درباره سامانه‌های پشتیبانی‌کننده از این گزینه و محدودیت‌های آن، بخش Preventing shell escapes را ببینید. این تنظیم فقط در نسخه 1.9.8 یا بالاتر پشتیبانی می‌شود و با پشتیبانی SELinux RBAC ناسازگار است، مگر اینکه سامانه از حالت فیلتر seccomp(2) پشتیبانی کند.

log_ttyin

در صورت تنظیم، sudo دستور را در یک شبه‌ترمینال اجرا کرده و کلیدهای فشرده‌شده توسط کاربر را در صورت وجود ترمینال کاربر، ثبت می‌کند. این پرچم به‌طور پیش‌فرض off است، اما زمانی که پرچم log_input یا برچسب دستور LOG_INPUT تنظیم شده باشد، فعال می‌شود. اگر ترمینالی وجود نداشته باشد، مثلاً هنگام اجرای یک دستور از راه دور با استفاده از ssh(1), این پرچم هیچ اثری نخواهد داشت.

log_ttyout

در صورت تنظیم، sudo دستور را در یک شبه‌ترمینال اجرا کرده و تمام خروجی‌های نمایش‌داده‌شده روی ترمینال کاربر را، در صورت وجود ترمینال، ثبت می‌کند. این پرچم به‌طور پیش‌فرض off است، اما زمانی که پرچم log_output یا برچسب دستور LOG_OUTPUT تنظیم شده باشد، فعال می‌شود. اگر ترمینالی وجود نداشته باشد، مثلاً هنگام اجرای یک دستور از راه دور با استفاده از ssh(1), این پرچم هیچ اثری نخواهد داشت.

log_year

در صورت تنظیم، سال چهاررقمی در پرونده لاگ (غیر syslog) sudo ثبت خواهد شد. این پرچم به‌طور پیش‌فرض off است.

long_otp_prompt

هنگام اعتبارسنجی با یک طرح گذرواژه یک‌بارمصرف (OTP) مانند S/Key یا OPIE, یک اعلان دوخطی استفاده می‌شود تا برش و چسباندن چالش به پنجره محلی آسان‌تر شود. این حالت به زیبایی پیش‌فرض نیست، اما برخی آن را راحت‌تر می‌دانند. این پرچم به‌طور پیش‌فرض off است.

mail_all_cmnds

هر بار که کاربری تلاش کند دستوری را از طریق sudo اجرا کند، به کاربر mailto رایانامه می‌فرستد (این شامل sudoedit). می‌شود). اگر کاربر sudo را با گزینه -l یا -v اجرا کند، هیچ رایانامه‌ای فرستاده نخواهد شد مگر اینکه خطای احراز هویت رخ دهد و پرچم mail_badpass نیز تنظیم شده باشد. این پرچم به‌طور پیش‌فرض off است.

mail_always

هر بار که کاربری sudo را اجرا کند، به کاربر mailto رایانامه می‌فرستد. این پرچم به‌طور پیش‌فرض off است.

mail_badpass

ارسال رایانامه به کاربر mailto اگر کاربر اجراکنندهٔ sudo گذرواژهٔ درست را وارد نکند. اگر دستوری که کاربر برای اجرای آن تلاش می‌کند توسط sudoers مجاز نباشد و یکی از پرچم‌های mail_all_cmnds, mail_always, mail_no_host, mail_no_perms یا mail_no_user تنظیم شده باشد، این پرچم بی‌اثر خواهد بود. این پرچم به‌طور پیش‌فرض off است.

mail_no_host

در صورت تنظیم بودن، رایانامه به کاربر mailto ارسال می‌شود اگر کاربر فراخواننده در پروندهٔ sudoers وجود داشته باشد، اما مجاز به اجرای دستورها روی میزبان فعلی نباشد. این پرچم به‌طور پیش‌فرض off است.

mail_no_perms

در صورت تنظیم بودن، رایانامه به کاربر mailto ارسال می‌شود اگر کاربر فراخواننده مجاز به استفاده از sudo باشد، اما دستوری که برای اجرای آن تلاش می‌کند در مدخل پروندهٔ sudoers او فهرست نشده یا صریحاً رد شده باشد. این پرچم به‌طور پیش‌فرض off است.

mail_no_user

در صورت تنظیم بودن، رایانامه به کاربر mailto ارسال می‌شود اگر کاربر فراخواننده در پروندهٔ sudoers نباشد. این پرچم به‌طور پیش‌فرض on است.

match_group_by_gid

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

اگر match_group_by_gid فعال باشد، جستجوهای پایگاه‌دادهٔ گروه که توسط sudoers انجام می‌شوند، برخلاف شناسهٔ گروه، بر اساس نام گروه کلید خواهند خورد. روی سیستم‌هایی که چند منبع برای پایگاه‌دادهٔ گروه دارند، احتمال وجود تداخل در نام‌های گروه یا شناسه‌های گروه بین پروندهٔ محلی /etc/group و پایگاه‌دادهٔ دوردست گروه وجود دارد. در چنین سیستم‌هایی، فعال یا غیرفعال کردن match_group_by_gid می‌تواند برای تعیین اینکه پرس‌وجوهای پایگاه‌دادهٔ گروه بر اساس نام (فعال) یا شناسه (غیرفعال) انجام شوند استفاده شود، که ممکن است به دور زدن تداخل مدخل‌های گروه کمک کند.

پرچم match_group_by_gid هنگامی که داده‌های sudoers در LDAP ذخیره شده باشند، هیچ تأثیری ندارد. این پرچم به طور پیش‌فرض off است.

این تنظیم فقط در نسخهٔ 1.8.18 یا بالاتر پشتیبانی می‌شود.

intercept

در صورت تنظیم، تمام دستورهای اجرا شده از طریق sudo به گونه‌ای رفتار خواهند کرد که گویی برچسب INTERCEPT تنظیم شده است، مگر اینکه توسط برچسب NOINTERCEPT لغو شود. توضیحات INTERCEPT and NOINTERCEPT در بالا و همچنین بخش Preventing shell escapes در انتهای این راهنما را ببینید. این پرچم به طور پیش‌فرض off است.

این تنظیم فقط در نسخهٔ 1.9.8 یا بالاتر پشتیبانی می‌شود و با پشتیبانی از SELinux RBAC ناسازگار است مگر اینکه سیستم از حالت فیلتر seccomp(2) پشتیبانی کند.

intercept_allow_setid

در بیشتر سیستم‌ها، بارگذار پویا هنگام اجرای برنامه‌های set-user-ID و set-group-ID متغیر LD_PRELOAD (یا معادل آن) را نادیده می‌گیرد و در عمل حالت رهگیری را غیرفعال می‌کند. برای جلوگیری از این امر، sudoers اجازه اجرای برنامهٔ set-user-ID یا set-group-ID را در حالت رهگیری نخواهد داد مگر اینکه intercept_allow_setid فعال باشد. این پرچم هیچ تأثیری ندارد مگر اینکه پرچم intercept فعال باشد یا برچسب INTERCEPT برای دستور تنظیم شده باشد. این پرچم به طور پیش‌فرض هنگامی که گزینهٔ intercept_type روی trace تنظیم شده باشد on است، در غیر این صورت به طور پیش‌فرض off می‌باشد.

این تنظیم فقط در نسخهٔ 1.9.8 یا بالاتر پشتیبانی می‌شود.

intercept_authenticate

در صورت تنظیم، دستورهای اجرا شده توسط فرایندِ تحت رهگیری باید در صورت معتبر نبودن برچسب زمانی کاربر، احراز هویت شوند. برای مثال، اگر یک شل با intercept فعال اجرا شود، به محض اینکه برچسب زمانی کاربر منقضی شود، دستورهای بعدی باید احراز هویت شوند. این پرچم هیچ تأثیری ندارد مگر اینکه پرچم intercept فعال باشد یا برچسب INTERCEPT برای دستور تنظیم شده باشد. این پرچم به طور پیش‌فرض off است.

این تنظیم فقط در نسخهٔ 1.9.8 یا بالاتر پشتیبانی می‌شود.

intercept_verify

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

فرایند پس از تکمیل execve(2) اما پیش از اینکه دستور جدید فرصت اجرا پیدا کند متوقف خواهد شد. برای تأیید دستور، sudo مسیر دستور را از /proc/PID/exe ، آرگومان‌های خط فرمان و محیط را از حافظهٔ فرایند می‌خواند و آن‌ها را با آرگومان‌های ارسال‌شده به execve(2) مقایسه می‌کند. در صورت عدم تطابق، به دستور سیگنال SIGKILL ارسال شده و خاتمه داده می‌شود.

این می‌تواند به جلوگیری از مسئله زمان بررسی در برابر زمان استفاده در حالت رهگیری کمک کند؛ جایی که آرگومان‌های execve(2) می‌توانند پس از بررسی سیاست sudoers تغییر یابند. این بررسی‌ها تنها در صورتی قابل انجام هستند که سیستم‌فایل proc(5) در دسترس باشد. این پرچم هیچ تاثیری ندارد مگر اینکه پرچم intercept فعال باشد یا برچسب INTERCEPT برای دستور تنظیم شده باشد و گزینه intercept_type روی trace تنظیم شده باشد. این پرچم به طور پیش‌فرض on است.

این تنظیم تنها در نگارش 1.9.12 یا بالاتر پشتیبانی می‌شود.

netgroup_tuple

در صورت تنظیم، جستجوهای netgroup با استفاده از چندتایی کامل netgroup انجام می‌شوند: نام میزبان، نام کاربر، و دامنه (در صورت تعیین). از نظر تاریخی، sudo تنها نام کاربر و دامنه را برای netgroupهای استفاده‌شده در یک User_List تطبیق می‌داد و تنها نام میزبان و دامنه را برای netgroupهای استفاده‌شده در یک Host_List تطبیق می‌داد. این پرچم به طور پیش‌فرض off است.

noexec

در صورت تنظیم، تمام دستورهای اجرا شده از طریق sudo طوری رفتار خواهند کرد که گویی برچسب NOEXEC تنظیم شده است، مگر اینکه توسط یک برچسب EXEC لغو شود. توضیحات EXEC and NOEXEC در بالا و همچنین بخش Preventing shell escapes در انتهای این دفترچه راهنما را ببینید. این پرچم به طور پیش‌فرض off است.

noninteractive_auth

در صورت تنظیم، احراز هویت حتی در حالت غیرتعاملی تلاش خواهد شد (زمانی که گزینه -n از sudoمشخص شده باشد). این به روش‌های احراز هویتی که نیازی به تعامل کاربر ندارند امکان موفقیت می‌دهد. روش‌های احراز هویتی که نیاز به ورودی از ترمینال کاربر دارند همچنان ناموفق خواهند بود. در صورت غیرفعال بودن، تلاشی برای احراز هویت در حالت غیرتعاملی صورت نخواهد گرفت. این پرچم به طور پیش‌فرض off است.

این تنظیم تنها در نگارش 1.9.10 یا بالاتر پشتیبانی می‌شود.

pam_acct_mgmt

در سیستم‌هایی که از PAM برای احراز هویت استفاده می‌کنند، sudo به طور پیش‌فرض اعتبارسنجی حساب PAM را برای کاربر فراخوان انجام می‌دهد. بررسی‌های واقعی انجام‌شده بستگی به این دارد که کدام ماژول‌های PAM پیکربندی شده باشند. در صورت فعال بودن، اعتبارسنجی حساب صرف‌نظر از نیاز یا عدم نیاز به گذرواژه انجام خواهد شد. این پرچم به طور پیش‌فرض on است.

این تنظیم تنها در نگارش 1.8.28 یا بالاتر پشتیبانی می‌شود.

pam_rhost

در سیستم‌هایی که از PAM برای احراز هویت استفاده می‌کنند، sudo مقدار میزبان دوردست PAM را به نام میزبان محلی تنظیم می‌کند زمانی که پرچم pam_rhost فعال باشد. در سیستم‌های لینوکس، فعال کردن pam_rhost ممکن است منجر به جستجوهای DNS برای نام میزبان محلی هنگام مقداردهی اولیه PAM شود. در نگارش‌های Solaris پیش از Solaris 8، pam_rhost باید فعال باشد اگر pam_ruser نیز فعال شده باشد تا از کرش در پیاده‌سازی PAM در Solaris جلوگیری شود.

این پرچم در سیستم‌هایی به جز Solaris به طور پیش‌فرض off است.

این تنظیم تنها در نگارش 1.9.0 یا بالاتر پشتیبانی می‌شود.

pam_ruser

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

این تنظیم تنها در نسخهٔ 1.9.0 یا بالاتر پشتیبانی می‌شود.

pam_session

در سامانه‌هایی که از PAM برای احراز هویت استفاده می‌کنند، sudo یک نشست PAM جدید برای اجرای دستور در آن ایجاد می‌کند. مگر این که به sudo گزینه‌های -i یا -s داده شود، ماژول‌های نشست PAM با پرچم فعال‌شدهٔ “silent” اجرا می‌شوند. این کار از نمایش اطلاعات آخرین ورود برای هر دستور در برخی سامانه‌ها جلوگیری می‌کند. غیرفعال کردن pam_session ممکن است در پیاده‌سازی‌های قدیمی‌تر PAM یا در سیستم‌عامل‌هایی نیاز باشد که باز کردن یک نشست PAM پرونده‌های utmp یا wtmp را تغییر می‌دهد. اگر پشتیبانی از نشست PAM غیرفعال باشد، ممکن است محدودیت‌های منابع برای دستوری که اجرا می‌شود به‌روز نشوند. اگر pam_session, pam_setcred, و use_pty غیرفعال باشند، log_servers تنظیم نشده باشد و گزارش‌گیری I/O پیکربندی نشده باشد، sudo دستور را مستقیماً به‌جای اجرا در قالب یک فرایند فرزند اجرا خواهد کرد. این پرچم به صورت پیش‌فرض on است.

این تنظیم تنها در نسخهٔ 1.8.7 یا بالاتر پشتیبانی می‌شود.

pam_setcred

در سامانه‌هایی که از PAM برای احراز هویت استفاده می‌کنند، sudo در صورت پشتیبانی سیستم احراز هویت زیربنایی، به‌طور پیش‌فرض تلاش می‌کند تا اعتبارات را برای کاربر هدف برقرار سازد. یک نمونه از اعتبارها، بلیت Kerberos است. اگر pam_session, pam_setcred, و use_pty غیرفعال باشند، log_servers تنظیم نشده باشد و گزارش‌گیری I/O پیکربندی نشده باشد، sudo دستور را مستقیماً به‌جای اجرا در قالب یک فرایند فرزند اجرا خواهد کرد. این پرچم به صورت پیش‌فرض on است.

این تنظیم تنها در نسخهٔ 1.8.8 یا بالاتر پشتیبانی می‌شود.

passprompt_override

در صورت تنظیم، اعلانی که توسط passprompt یا متغیر محیطی SUDO_PROMPT مشخص شده است همواره استفاده خواهد شد و جایگزین اعلان ارائه‌شده توسط یک ماژول PAM یا دیگر روش‌های احراز هویت می‌شود. این پرچم به صورت پیش‌فرض off است.

path_info

به‌طور معمول، sudo هنگامی که دستوری در متغیر محیطی PATH کاربر پیدا نشود، به او اطلاع می‌دهد. برخی پایگاه‌ها ممکن است بخواهند این قابلیت را غیرفعال کنند زیرا می‌تواند برای جمع‌آوری اطلاعات دربارهٔ محل فایل‌های اجرایی که کاربر عادی به آن‌ها دسترسی ندارد، استفاده شود. نقطه ضعف این است که اگر فایل اجرایی صرفاً در PATH کاربر نباشد، sudo به کاربر خواهد گفت که مجاز به اجرای آن نیست، که می‌تواند گیج‌کننده باشد. این پرچم به صورت پیش‌فرض on است.

preserve_groups

به‌طور پیش‌فرض، sudo بردار گروه را به فهرست گروه‌هایی که کاربر هدف در آن‌ها عضویت دارد مقداردهی اولیه می‌کند. هنگامی که preserve_groups تنظیم شده باشد، بردار گروه فعلی کاربر بدون تغییر باقی می‌ماند. با این حال، شناسه‌های کاربریِ گروهی (group-IDs) واقعی و مؤثر همچنان مطابق با کاربر هدف تنظیم می‌شوند. این پرچم به‌طور پیش‌فرض off است.

pwfeedback

به‌طور پیش‌فرض، sudo مانند بیشتر برنامه‌های یونیکس، با خاموش کردن بازتاب نویسه‌ها (echo) تا زمانی که کاربر کلید return (یا enter) را فشار دهد، گذرواژه را می‌خواند. برخی کاربران از این موضوع سردرگم می‌شوند چرا که به نظرشان می‌رسد sudo در این مرحله قفل کرده است. هنگامی که pwfeedback تنظیم شده باشد، sudo هنگام فشردن هر کلید توسط کاربر بازخورد بصری ارائه می‌دهد. این موضوع اثر امنیتی دارد، زیرا ممکن است افراد ناظر بتوانند طول گذرواژهٔ واردشده را تشخیص دهند. این پرچم به‌طور پیش‌فرض off است.

requiretty

در صورت تنظیم، sudo تنها زمانی اجرا می‌شود که کاربر در یک tty واقعی وارد سیستم شده باشد. هنگامی که این پرچم تنظیم باشد، sudo تنها از درون یک نشست ورود قابل اجرا است و نه از راه‌های دیگر نظیر cron(8) یا اسکریپت‌های cgi-bin. این پرچم به‌طور پیش‌فرض off است.

root_sudo

در صورت تنظیم، root نیز مجاز به اجرای sudo خواهد بود. غیرفعال کردن این گزینه مانع از “زنجیره‌کردن” دستورهای sudo توسط کاربران برای دستیابی به پوستهٔ root از طریق کارهایی مانند ‘sudo sudo /bin/sh’. می‌شود. با این حال توجه داشته باشید که غیرفعال کردن root_sudo همچنین مانع از اجرای sudoedit توسط root می‌شود. غیرفعال کردن root_sudo هیچ امنیت مضاعف واقعی فراهم نمی‌کند؛ این گزینه صرفاً به دلایل تاریخی وجود دارد. این پرچم به‌طور پیش‌فرض on است.

rootpw

در صورت تنظیم، sudo هنگام اجرای یک دستور یا ویرایش یک پرونده، به‌جای گذرواژهٔ کاربر فراخواننده، گذرواژهٔ root را درخواست می‌کند. این پرچم به‌طور پیش‌فرض off است.

runas_allow_unknown_id

در صورت فعال بودن، امکان تطبیق شناسه‌های کاربری و گروهیِ runas که در پایگاه‌های دادهٔ گذرواژه یا گروه وجود ندارند را می‌دهد. علاوه بر تطبیق صریح شناسه‌های کاربری یا گروهی ناشناخته در یک Runas_List, این گزینه همچنین به نام مستعار ALL اجازه می‌دهد با شناسهٔ ناشناخته تطبیق یابد. این پرچم به‌طور پیش‌فرض off است.

این تنظیم تنها در نسخهٔ 1.8.30 یا بالاتر پشتیبانی می‌شود. نسخه‌های قدیمی‌تر sudo همواره اجازهٔ تطبیق شناسه‌های کاربری و گروهی ناشناخته را می‌دادند.

runas_check_shell

در صورت فعال بودن، sudo تنها دستورها را تحت کاربری اجرا می‌کند که شل آن در پروندهٔ /etc/shells آمده باشد، حتی اگر Runas_List کاربر فراخواننده در حالت عادی اجازهٔ آن را بدهد. اگر پروندهٔ /etc/shells وجود نداشته باشد، فهرستی از شل‌های پیش‌فرضِ وابسته به سیستم به کار می‌رود. در بسیاری از سیستم‌عامل‌ها، کاربران سیستمی مانند “bin”, شل معتبری ندارند و از این پرچم می‌توان برای جلوگیری از اجرای دستورها تحت این کاربران بهره برد. این پرچم به صورت پیش‌فرض off است.

این تنظیم فقط در نسخهٔ 1.8.30 یا بالاتر پشتیبانی می‌شود.

runaspw

در صورت تنظیم، sudo به جای گذرواژهٔ کاربر فراخواننده، هنگام اجرای دستور یا ویرایش پرونده، گذرواژهٔ کاربر مشخص‌شده در گزینهٔ runas_default (به طور پیش‌فرض root) را درخواست می‌کند. این پرچم به صورت پیش‌فرض off است.

selinux

در صورت فعال بودن، کاربر می‌تواند هنگام اجرای دستور طبق دسترسی‌های خط‌مشی SELinux، یک نقش (role) یا نوع (type) SELinux تعیین کند. اگر SELinux در سیستم غیرفعال باشد، این پرچم اثری ندارد. این پرچم به صورت پیش‌فرض on است.

set_home

در صورت فعال بودن و فراخوانی sudo همراه با گزینهٔ -s -، متغیر محیطی HOME روی دایرکتوری خانگی کاربر هدف تنظیم می‌شود (که همان کاربر runas_default است مگر اینکه گزینهٔ -u به کار رفته باشد). این پرچم تا حد زیادی منسوخ است و هیچ اثری ندارد مگر آنکه پرچم env_reset غیرفعال شده یا HOME در فهرست env_keep آمده باشد، که انجام هر دوی این موارد شدیداً نهی می‌شود. این پرچم به صورت پیش‌فرض off است.

set_logname

به طور معمول، sudo متغیرهای محیطی LOGNAME و USER را روی نام کاربر هدف تنظیم می‌کند (کاربر مشخص‌شده در runas_default مگر اینکه گزینهٔ -u داده شده باشد). با این حال، از آنجا که برخی برنامه‌ها (از جمله سیستم مدیریت نسخه RCS) از LOGNAME برای تعیین هویت واقعی کاربر استفاده می‌کنند، ممکن است تغییر این رفتار مطلوب باشد. این تغییر با نفی کردن گزینهٔ set_logname امکان‌پذیر است. گزینهٔ set_logname هیچ اثری نخواهد داشت اگر گزینهٔ env_reset غیرفعال نشده باشد و فهرست env_keep حاوی LOGNAME یا USER. باشد. این پرچم به صورت پیش‌فرض on است.

set_utmp

در صورت فعال بودن، sudo هنگام تخصیص یک شبه‌ترمینال، مدخلی در پرونده utmp (یا utmpx) ایجاد می‌کند. یک شبه‌ترمینال توسط sudo زمانی تخصیص می‌یابد که در یک ترمینال اجرا شود و یک یا چند مورد از پرچم‌های log_input, log_output, log_stdin, log_stdout, log_stderr, log_ttyin, log_ttyout, یا use_pty فعال باشند. به‌طور پیش‌فرض، مدخل جدید رونوشتی از مدخل utmp موجود کاربر (در صورت وجود) خواهد بود که فیلدهای tty، time، type و pid آن به‌روزرسانی شده‌اند. این پرچم به‌طور پیش‌فرض on است.

setenv

به کاربر اجازه می‌دهد گزینه env_reset را از طریق خط فرمان با استفاده از گزینه -E غیرفعال کند. علاوه بر این، متغیرهای محیطی تنظیم‌شده از طریق خط فرمان مشمول محدودیت‌های اعمال‌شده توسط env_check, env_delete, یا env_keep نخواهند بود. بنابراین، تنها به کاربران مورد اعتماد باید اجازه تنظیم متغیرها به این شیوه داده شود. این پرچم به‌طور پیش‌فرض off است.

shell_noargs

اگر تنظیم شود و sudo بدون آرگومان فراخوانی شود، به گونه‌ای عمل می‌کند که گویی گزینه -s داده شده است. یعنی، یک پوسته را با عنوان root اجرا می‌کند (در صورت تنظیم بودن، پوسته توسط متغیر محیطی SHELL تعیین می‌شود، و در غیر این صورت به پوسته درج‌شده در مدخل /etc/passwd کاربر فراخوان بازمی‌گردد). این پرچم به‌طور پیش‌فرض off است.

stay_setuid

در حالت عادی، وقتی sudo دستوری را اجرا می‌کند، شناسه‌های کاربری واقعی و مؤثر روی کاربر هدف تنظیم می‌شوند (root به‌طور پیش‌فرض). این گزینه رفتار مذکور را به گونه‌ای تغییر می‌دهد که شناسه کاربری واقعی همان شناسه کاربری کاربر فراخوان باقی بماند. به عبارت دیگر، این کار باعث می‌شود sudo به عنوان یک لفاف set-user-ID عمل کند. این می‌تواند در سیستم‌هایی مفید باشد که برخی قابلیت‌های بالقوه خطرناک را هنگام اجرای یک برنامه با وضعیت set-user-ID غیرفعال می‌کنند. این گزینه تنها روی سیستم‌هایی مؤثر است که از فراخوانی سیستم setreuid(2) یا setresuid(2) پشتیبانی می‌کنند. این پرچم به‌طور پیش‌فرض off است.

sudoedit_checkdir

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

این تنظیم ابتدا در نگارش 1.8.15 معرفی شد اما در ابتدا از یک شرایط رقابتی رنج می‌برد. بررسی پیوندهای نمادین در دایرکتوری‌های میانی قابل نوشتن در نگارش 1.8.16 اضافه شد.

sudoedit_follow

به‌طور پیش‌گزیده، sudoedit هنگام باز کردن پرونده‌ها، پیوندهای نمادین را دنبال نخواهد کرد. گزینهٔ sudoedit_follow می‌تواند فعال شود تا به sudoedit اجازه باز کردن پیوندهای نمادین داده شود. این مقدار را می‌توان به ازای هر فرمان با برچسب‌های FOLLOW و NOFOLLOW بازنویسی کرد. این پرچم به‌طور پیش‌گزیده off است.

این تنظیم تنها در نگارش 1.8.15 یا بالاتر پشتیبانی می‌شود.

syslog_pid

هنگام ثبت گزارش از طریق syslog(3), شناسهٔ فرایند در مدخل گزارش گنجانده می‌شود. این پرچم به‌طور پیش‌گزیده off است.

این تنظیم تنها در نگارش 1.8.21 یا بالاتر پشتیبانی می‌شود.

targetpw

در صورت تنظیم، sudo هنگام اجرای یک فرمان یا ویرایش یک پرونده، به‌جای گذرواژهٔ کاربر فراخواننده، گذرواژهٔ کاربر مشخص‌شده توسط گزینهٔ -u (به‌طور پیش‌گزیده مقدار runas_default) را درخواست خواهد کرد. این پرچم از استفاده از شناسهٔ کاربری ثبت‌نشده در پایگاه‌دادهٔ passwd به‌عنوان آرگومان برای گزینهٔ -u جلوگیری می‌کند. این پرچم به‌طور پیش‌گزیده off است.

tty_tickets

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

این گزینه با گزینهٔ timestamp_type جایگزین شده است.

umask_override

در صورت تنظیم، sudo مقدار umask را دقیقاً همان‌گونه که در پروندهٔ sudoers مشخص شده است بدون تغییر تنظیم خواهد کرد. این کار امکان تعیین umask در پروندهٔ sudoers را فراهم می‌کند که دسترسی آزادتری نسبت به umask خود کاربر داشته و با رفتار پیشین مطابقت دارد. اگر umask_override تنظیم نشده باشد، sudo مقدار umask را برابر با اجتماع umask کاربر و مقدار مشخص‌شده در sudoers قرار خواهد داد. این پرچم به‌طور پیش‌گزیده off است.

use_netgroups

در صورت تنظیم، گروه‌های شبکه (با پیشوند ‘+) ،’ می‌توانند به جای کاربر یا میزبان استفاده شوند. برای sudoers مبتنی بر LDAP، پشتیبانی از گروه‌های شبکه نیازمند یک تطابق زیررشته‌ای سنگین روی سرور است مگر اینکه دستورالعمل NETGROUP_BASE در پرونده‌ی /etc/ldap.conf وجود داشته باشد. اگر به گروه‌های شبکه نیازی نباشد، این گزینه می‌تواند برای کاهش بار روی سرور LDAP غیرفعال شود. این پرچم به طور پیش‌فرض on است.

use_pty

در صورت تنظیم و در حالتی که sudo در یک ترمینال اجرا شود، دستور در یک شبه‌ترمینال اجرا خواهد شد (حتی اگر هیچ ثبت وقایع ورودی/خروجی انجام نشود). اگر فرایند sudo به یک ترمینال متصل نباشد، use_pty هیچ تأثیری ندارد.

یک برنامه‌ی مخرب که تحت sudo اجرا می‌شود ممکن است بتواند دستورهایی را به ترمینال کاربر تزریق کند یا فرایندی در پس‌زمینه اجرا کند که حتی پس از پایان اجرای برنامه‌ی اصلی، دسترسی به دستگاه ترمینال کاربر را حفظ کند. با اجرای دستور در یک شبه‌ترمینال جداگانه، این حمله دیگر امکان‌پذیر نخواهد بود. این پرچم به طور پیش‌فرض off است.

user_command_timeouts

در صورت تنظیم، کاربر می‌تواند یک مهلت زمانی در خط فرمان مشخص کند. اگر مهلت زمانی پیش از پایان یافتن دستور منقضی شود، دستور خاتمه خواهد یافت. اگر مهلت زمانی هم در پرونده‌ی sudoers و هم در خط فرمان مشخص شده باشد، مقدار کمتر از بین آن دو استفاده خواهد شد. برای شرح ساختار مهلت زمانی، بخش Timeout_Spec را ببینید. این پرچم به طور پیش‌فرض off است.

این تنظیم تنها در نگارش 1.8.20 یا بالاتر پشتیبانی می‌شود.

utmp_runas

در صورت تنظیم، sudo نام کاربری که دستور با هویت آن اجرا می‌شود (runas) را هنگام به‌روزرسانی پرونده‌ی utmp (یا utmpx) ذخیره می‌کند. به طور پیش‌فرض، sudo نام کاربر فراخواننده را ذخیره می‌کند. این پرچم به طور پیش‌فرض off است.

visiblepw

به طور پیش‌فرض، sudo اگر کاربر مجبور به وارد کردن گذرواژه باشد اما غیرفعال کردن انعکاس (echo) در ترمینال ممکن نباشد، از اجرا خودداری می‌کند. اگر پرچم visiblepw تنظیم شده باشد، sudo حتی زمانی که گذرواژه روی صفحه نمایش قابل مشاهده باشد، درخواست گذرواژه خواهد کرد. این قابلیت اجرای دستورهایی مانند ‘ssh somehost sudo ls’ را ممکن می‌سازد، چرا که به طور پیش‌فرض، ssh(1) هنگام اجرای یک دستور، tty تخصیص نمی‌دهد. این پرچم به طور پیش‌فرض off است.

اعداد صحیح:

closefrom

پیش از اجرای یک دستور، sudo تمام توصیف‌کننده‌های باز پرونده به جز ورودی استاندارد، خروجی استاندارد و خطای استاندارد (توصیف‌کننده‌های پرونده 0-2) را خواهد بست. گزینه‌ی closefrom می‌تواند برای تعیین یک توصیف‌کننده‌ی پرونده‌ی متفاوت جهت شروع بستن استفاده شود. مقدار پیش‌فرض 3 است.

command_timeout

حداکثر مدت زمانی که یک دستور پیش از خاتمه یافتن اجازه اجرا دارد. برای توضیحات مربوط به نحو مهلت زمانی، بخش Timeout_Spec را ببینید.

این تنظیم تنها در نسخه 1.8.20 یا بالاتر پشتیبانی می‌شود.

log_server_timeout

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

این تنظیم تنها در نسخه 1.9.0 یا بالاتر پشتیبانی می‌شود.

maxseq

حداکثر شماره توالی که جایگزین کد گریز ‘%{seq}’ در پرونده گزارش I/O خواهد شد (برای اطلاعات بیشتر توضیحات iolog_dir را در زیر ببینید). در حالی که مقدار جایگزین‌شده برای ‘%{seq}’ در مبنای ۳۶ است، خود maxseq باید در مبنای ده‌دهی بیان شود. مقادیر بزرگ‌تر از 2176782336 (که متناظر با شماره توالی در مبنای ۳۶ “ZZZZZZ”) است، بدون هشدار به 2176782336 کوتاه می‌شوند. مقدار پیش‌فرض 2176782336 است.

به محض اینکه شماره توالی محلی به مقدار maxseq برسد، به صفر “سرریز” خواهد کرد، که پس از آن sudoers نام مسیرهای گزارش I/O موجود را کوتاه و مجدداً استفاده خواهد کرد.

این تنظیم تنها در نسخه 1.8.7 یا بالاتر پشتیبانی می‌شود.

passwd_tries

تعداد دفعاتی که کاربر مجاز است گذرواژه خود را پیش از اینکه sudo شکست را ثبت کرده و خارج شود وارد کند. مقدار پیش‌فرض ۳ است.

syslog_maxlen

در بسیاری از سیستم‌ها، syslog(3) بافر گزارش نسبتاً کوچکی دارد. سند IETF RFC 5424 بیان می‌کند که سرورهای syslog باید از پیام‌های حداقل ۴۸۰ بایتی پشتیبانی کنند و بهتر است از پیام‌های تا ۲۰۴۸ بایت پشتیبانی به عمل آورند. به‌طور پیش‌فرض، sudoers پیام‌های گزارشی تا ۹۸۰ بایت ایجاد می‌کند که متناظر با پیاده‌سازی تاریخی BSD در syslog است؛ پیاده‌سازی‌ای که از یک بافر ۱۰۲۴ بایتی برای ذخیره پیام، تاریخ، نام میزبان و نام برنامه استفاده می‌کرد. برای جلوگیری از بریده شدن پیام‌های syslog، sudoers پیام‌های گزارشی بزرگ‌تر از syslog_maxlen بایت را به چند بخش تقسیم خواهد کرد. هنگامی که پیامی تقسیم می‌شود، بخش‌های اضافه شامل رشته “(command continued)” بعد از نام کاربری و قبل از ادامه آرگومان‌های خط فرمان خواهند بود.

این تنظیم تنها در نسخه 1.8.19 یا بالاتر پشتیبانی می‌شود.

اعداد صحیحی که می‌توانند در زمینه بولی استفاده شوند:

loglinelen

تعداد نویسه‌ها در هر سطر برای گزارش پرونده. این مقدار برای تصمیم‌گیری درباره زمان شکستن سطرها جهت خوانایی بهتر پرونده‌های گزارش استفاده می‌شود. این گزینه تأثیری بر پرونده گزارش syslog ندارد و فقط بر گزارش پرونده مؤثر است. مقدار پیش‌فرض ۸۰ است (از ۰ استفاده کنید یا گزینه را نفی کنید تا شکستن خودکار سطرها غیرفعال شود).

passwd_timeout

تعداد دقایق پیش از اتمام مهلت اعلان گذرواژه sudo یا ۰ برای بدون محدودیت زمانی. در صورتی که دقت در سطح دقیقه کافی نباشد، مهلت زمانی می‌تواند شامل مقدار اعشاری نیز باشد، برای مثال 2.5. مقدار پیش‌فرض ۰ است.

timestamp_timeout

تعداد دقیقه‌هایی که می‌تواند پیش از درخواست مجدد گذرواژه توسط sudo سپری شود. اگر دقت در مقیاس دقیقه کافی نباشد، زمان مهلت می‌تواند شامل یک جزء اعشاری باشد، مثلاً 2.5. مقدار پیش‌فرض 15 است. برای درخواست همیشگی گذرواژه، این مقدار را 0 بگذارید. در صورت تنظیم به مقداری کمتر از 0، برچسب زمانی کاربر تا زمان راه‌اندازی مجدد سیستم منقضی نخواهد شد. از این قابلیت می‌توان برای اجازه دادن به کاربران جهت ایجاد یا حذف برچسب‌های زمانی خود به‌ترتیب از طریق ‘sudo -v’ و ‘sudo -k’ استفاده کرد.

umask

ماسک حالت ایجاد فایل برای استفاده هنگام اجرای دستور. برای جلوگیری از تغییر umask توسط sudoers این گزینه را نفی کنید یا آن را روی 0777 بگذارید. مگر اینکه پرچم umask_override تنظیم شده باشد، umask واقعی حاصل اجتماع umask کاربر و مقدار تنظیم umask خواهد بود که مقدار پیش‌فرض آن 0022 است. این تضمین می‌کند که sudo هنگام اجرای یک دستور هرگز umask را تضعیف نمی‌کند.

اگر umask به‌صراحت در sudoers, تنظیم شده باشد، هرگونه تنظیم umask در PAM یا login.conf را بازنویسی خواهد کرد. اگر umask در sudoers, تنظیم نشده باشد، umask مشخص‌شده توسط PAM یا login.conf اولویت خواهد داشت. تنظیم umask در PAM برای sudoedit, که نشست جدید PAM ایجاد نمی‌کند، اعمال نمی‌شود.

Strings:

authfail_message

پیامی که پس از ناموفق بودن احراز هویت کاربر نمایش داده می‌شود. این پیام می‌تواند شامل توالی گریز ‘%d’ باشد که به تعداد تلاش‌های ناموفق ورود گذرواژه بسط می‌یابد. در صورت تنظیم، پیام پیش‌فرض را لغو می‌کند: “%d incorrect password attempt(s)”.

badpass_message

پیامی که در صورت وارد کردن گذرواژه نادرست توسط کاربر نمایش داده می‌شود. مقدار پیش‌فرض “Sorry, try again.” است مگر اینکه توهین‌ها فعال شده باشند.

editor

فهرستی جدا شده با دو‌نقطه (‘:’) از مسیرهای ویرایشگر مورد استفاده توسط sudoedit و visudo. برای sudoedit, این فهرست برای یافتن ویرایشگر استفاده می‌شود، هنگامی که هیچ‌یک از متغیرهای محیطی SUDO_EDITOR, VISUAL یا EDITOR روی ویرایشگری که موجود و قابل اجرا باشد تنظیم نشده باشند. برای visudo, به عنوان فهرست سفیدی از ویرایشگرهای مجاز استفاده می‌شود؛ visudo ویرایشگری را انتخاب خواهد کرد که با متغیر محیطی SUDO_EDITOR, VISUAL یا EDITOR کاربر در صورت امکان مطابقت داشته باشد، یا نخستین ویرایشگر در فهرست که موجود و قابل اجرا باشد در غیر این صورت. مگر اینکه به عنوان sudoedit, فراخوانی شود، sudo متغیرهای محیطی SUDO_EDITOR, VISUAL یا EDITOR را حفظ نمی‌کند، مگر اینکه در فهرست env_keep حضور داشته باشند یا گزینهٔ env_reset غیرفعال شده باشد. پیش‌فرض برابر است با /usr/bin/editor.

intercept_type

سازوکار زیربنایی مورد استفاده توسط گزینه‌های intercept و log_subcmds است. دارای مقادیر ممکن زیر است:

dso

پیش‌بارگذاری یک شیء اشتراکی پویا (کتابخانه اشتراکی) که توابع کتابخانه‌ای execve(2), execl(3), execle(3), execlp(3), execv(3), execvp(3), execvpe(3), و system(3) را رهگیری می‌کند. مقدار dso با پشتیبانی SELinux RBAC در sudo's ناسازگار است.

trace

استفاده از ptrace(2) برای رهگیری فراخوان سیستمی execve(2) است. این قابلیت تنها روی سیستم‌های لینوکسی پشتیبانی می‌شود که فیلترکردن seccomp(2) فعال باشد. اگر پروندهٔ /proc/sys/kernel/seccomp/actions_avail وجود نداشته باشد یا شامل یک عنصر “trap” نباشد، تنظیم intercept_type روی trace هیچ اثری نخواهد داشت و به جای آن از dso استفاده خواهد شد.

پیش‌فرض استفاده از trace است در صورتی که توسط سیستم پشتیبانی شود و dso در صورتی که پشتیبانی نشود.

iolog_dir

شاخهٔ ریشه برای ساخت مسیر شاخهٔ گزارش‌های ورودی/خروجی. تنها زمانی استفاده می‌شود که گزینه‌های log_input یا log_output فعال باشند، یا برچسب‌های LOG_INPUT یا LOG_OUTPUT برای فرمانی مشخص شده باشند. شمارهٔ ترتیب نشست، در صورت وجود، در این شاخه ذخیره می‌شود. پیش‌گزیده: /var/log/sudo-io.

دنباله‌های گریز درصد (‘%’) زیر پشتیبانی می‌شوند:

%{seq}

به یک شمارهٔ ترتیبی افزایشی در مبنای ۳۶ باز می‌شود (مانند 0100A5)، که هر دو رقم آن برای ساخت شاخه‌ای جدید به‌کار می‌رود، مانند 01/00/A5

%{user}

به نام کاربری کاربر اجراکننده باز می‌شود

%{group}

به نام گروه واقعی (real group-ID) کاربر اجراکننده باز می‌شود

%{runas_user}

به نام کاربری کاربری که فرمان با دسترسی آن اجرا خواهد شد باز می‌شود (مانند root)

%{runas_group}

به نام گروه کاربری که فرمان با دسترسی آن اجرا خواهد شد باز می‌شود (مانند wheel)

%{hostname}

به نام میزبان محلی بدون نام دامنه باز می‌شود

%{command}

به نام پایهٔ فرمان در حال اجرا باز می‌شود

علاوه بر این، تمام دنباله‌های گریز پشتیبانی‌شده توسط تابع strftime(3) سیستم نیز جایگزین می‌شوند.

برای درج نویسهٔ صریح ‘%’ باید از رشتهٔ ‘%%’ استفاده شود.

iolog_file

مسیر نسبی نسبت به iolog_dir, برای ذخیرهٔ گزارش‌های ورودی/خروجی در زمان فعال بودن log_input یا log_output یا وجود برچسب‌های LOG_INPUT یا LOG_OUTPUT برای یک فرمان. iolog_file می‌تواند شامل نام شاخه نیز باشد. پیش‌گزیده: ‘%{seq}’.

فهرست دنباله‌های گریز درصد (‘%’) پشتیبانی‌شده در توضیح گزینهٔ iolog_dir آمده است.

علاوه بر دنباله‌های گریز، مسیرهایی که به شش یا تعداد بیشتری Xs ختم شوند، این Xs ها با ترکیبی یکتا از ارقام و حروف جایگزین می‌شوند؛ مشابه تابع mktemp(3)

اگر مسیر حاصل از الحاق iolog_dir و iolog_file وجود داشته باشد، پروندهٔ لاگ موجود کوتاه (truncate) و بازنویسی می‌شود مگر اینکه iolog_file به شش یا تعداد بیشتری Xs. ختم شده باشد.

iolog_flush

در صورت تنظیم، sudo داده‌های گزارش I/O را پس از هر نوشتن به جای بافر کردن، روی دیسک تخلیه می‌کند. این کار مشاهده بلادرنگ گزارش‌ها را هنگام اجرای برنامه ممکن می‌سازد، اما ممکن است کارایی فشرده‌سازی گزارش‌های I/O را به میزان قابل توجهی کاهش دهد. این پرچم به طور پیش‌فرض off است.

این تنظیم فقط در نسخه 1.8.20 یا بالاتر پشتیبانی می‌شود.

iolog_group

نام گروه برای جستجو هنگام تنظیم شناسه گروه روی پرونده‌ها و دایرکتوری‌های جدید گزارش I/O. اگر iolog_group تنظیم نشده باشد، شناسه گروه اصلی کاربری که توسط iolog_user مشخص شده استفاده می‌شود. اگر هیچ‌کدام از iolog_group یا iolog_user تنظیم نشده باشند، پرونده‌ها و دایرکتوری‌های گزارش I/O با شناسه گروه 0 ایجاد می‌شوند.

این تنظیم فقط در نسخه 1.8.19 یا بالاتر پشتیبانی می‌شود.

iolog_mode

حالت پرونده مورد استفاده هنگام ایجاد پرونده‌های گزارش I/O. بیت‌های حالت برای مجوزهای خواندن و نوشتن مالک، گروه یا دیگران اعمال می‌شوند؛ سایر موارد نادیده گرفته خواهند شد. مجوزهای پرونده همواره شامل بیت‌های خواندن و نوشتن مالک خواهند بود، حتی اگر در حالت مشخص‌شده وجود نداشته باشند. هنگام ایجاد دایرکتوری‌های گزارش I/O، بیت‌های جستجو (اجرا) اضافه می‌شوند تا با بیت‌های خواندن و نوشتن مشخص‌شده توسط iolog_mode مطابقت داشته باشند. پیش‌فرض 0600 است (فقط خواندن و نوشتن توسط کاربر).

این تنظیم فقط در نسخه 1.8.19 یا بالاتر پشتیبانی می‌شود.

iolog_user

نام کاربر برای جستجو هنگام تنظیم شناسه‌های کاربر و گروه روی پرونده‌ها و دایرکتوری‌های جدید گزارش I/O. اگر iolog_group تنظیم شده باشد، به جای شناسه گروه اصلی کاربر استفاده خواهد شد. به طور پیش‌فرض، پرونده‌ها و دایرکتوری‌های گزارش I/O با شناسه کاربر و شناسه گروه 0 ایجاد می‌شوند.

این تنظیم زمانی که گزارش‌های I/O روی یک اشتراک سامانه پرونده شبکه‌ای (NFS) ذخیره می‌شوند، می‌تواند مفید باشد. داشتن یک کاربر اختصاصی به عنوان مالک پرونده‌های گزارش I/O بدان معناست که sudoers با شناسه کاربر 0 روی پرونده‌های گزارش نمی‌نویسد؛ امری که معمولاً توسط NFS مجاز دانسته نمی‌شود.

این تنظیم فقط در نسخه 1.8.19 یا بالاتر پشتیبانی می‌شود.

lecture_status_dir

دایرکتوری‌ای که sudo پرونده‌های وضعیت تذکر هر کاربر را در آن ذخیره می‌کند. به محض اینکه کاربر تذکر را دریافت کند، یک پرونده با اندازه صفر در این دایرکتوری ایجاد می‌شود تا sudo دوباره به کاربر تذکر ندهد. این دایرکتوری نباید هنگام راه‌اندازی مجدد سیستم پاک شود. پیش‌فرض /var/lib/sudo/lectured است.

log_server_cabundle

مسیر پرونده بسته مرجع صدور گواهی (CA bundle) در قالب PEM، جهت استفاده به جای پایگاه‌داده مراجع صدور گواهی پیش‌فرض سیستم هنگام احراز هویت کارساز گزارش. پیش‌فرض، استفاده از پایگاه‌داده مراجع صدور گواهی پیش‌فرض سیستم است. این تنظیم بی‌اثر است مگر اینکه log_servers تنظیم شده باشد و کارساز گزارش راه دور با TLS امن شده باشد.

این تنظیم فقط در نسخه 1.9.0 یا بالاتر پشتیبانی می‌شود.

log_server_peer_cert

مسیر پرونده گواهی کلاینت sudo در قالب PEM. این تنظیم زمانی لازم است که سرور گزارش دوردست با TLS امن شده باشد و اعتبارسنجی گواهی کلاینت فعال باشد. برای sudo_logsrvd, اعتبارسنجی گواهی کلاینت توسط گزینه tls_checkpeer کنترل می‌شود که مقدار پیش‌فرض آن false است.

این تنظیم فقط در نسخه 1.9.0 یا بالاتر پشتیبانی می‌شود.

log_server_peer_key

مسیر پرونده کلید خصوصی کلاینت sudo در قالب PEM. این تنظیم زمانی لازم است که سرور گزارش دوردست با TLS امن شده باشد و اعتبارسنجی گواهی کلاینت فعال باشد. برای sudo_logsrvd, اعتبارسنجی گواهی کلاینت توسط پرچم tls_checkpeer کنترل می‌شود که مقدار پیش‌فرض آن false است.

این تنظیم فقط در نسخه 1.9.0 یا بالاتر پشتیبانی می‌شود.

mailsub

موضوع نامه ارسال‌شده به کاربر mailto. کد گریز ‘%h’ به نام میزبان دستگاه گسترش می‌یابد. پیش‌فرض “*** SECURITY information for %h ***” است.

noexec_file

از نسخه 1.8.1 sudo این گزینه دیگر پشتیبانی نمی‌شود. مسیر پرونده noexec اکنون باید در پرونده sudo.conf(5) تنظیم شود.

pam_askpass_service

در سیستم‌هایی که از PAM برای احراز هویت استفاده می‌کنند، این نام سرویسی است که هنگام تعیین گزینه -A استفاده می‌شود. مقدار پیش‌فرض بسته به اینکه آیا گزینه -i نیز مشخص شده است یا خیر، ‘sudo’ یا ‘sudo-i’ است. برای اطلاعات بیشتر توضیحات pam_service را ببینید.

این تنظیم فقط در نسخه 1.9.9 یا بالاتر پشتیبانی می‌شود.

pam_login_service

در سیستم‌هایی که از PAM برای احراز هویت استفاده می‌کنند، این نام سرویسی است که هنگام تعیین گزینه -i استفاده می‌شود. مقدار پیش‌فرض ‘sudo-i’ است. برای اطلاعات بیشتر توضیحات pam_service را ببینید.

این تنظیم فقط در نسخه 1.8.8 یا بالاتر پشتیبانی می‌شود.

pam_service

در سیستم‌هایی که از PAM برای احراز هویت استفاده می‌کنند، نام سرویس سیاست PAM مورد اعمال را مشخص می‌کند. این مورد معمولاً با یک مدخل در پرونده pam.conf یا پرونده‌ای در شاخه /etc/pam.d مطابقت دارد. مقدار پیش‌فرض ‘sudo’ است.

این تنظیم فقط در نسخه 1.8.8 یا بالاتر پشتیبانی می‌شود.

passprompt

اعلان پیش‌فرض برای استفاده هنگام درخواست گذرواژه؛ می‌تواند از طریق گزینه -p یا متغیر محیطی SUDO_PROMPT بازنویسی شود. دنباله‌های گریز درصدی (‘%’) زیر پشتیبانی می‌شوند:

%H

به نام میزبان محلی به همراه نام دامنه گسترش می‌یابد (فقط اگر نام میزبان دستگاه کاملاً مشخص باشد یا گزینه fqdn تنظیم شده باشد)

%h

به نام میزبان محلی بدون نام دامنه گسترش می‌یابد

%p

به کاربری که گذرواژه‌اش درخواست شده گسترش می‌یابد (با در نظر گرفتن پرچم‌های rootpw, targetpw و runaspw در sudoers)

%U

به نام ورود کاربری که دستور در قالب آن اجرا خواهد شد گسترش می‌یابد (پیش‌فرض: root)

%u

به نام ورود کاربر فراخواننده گسترش می‌یابد

%%

دو نویسه متوالی ‘%’ به یک نویسه واحد ‘%’ تبدیل می‌شوند

در سامانه‌هایی که از PAM برای احراز هویت استفاده می‌کنند، passprompt تنها در صورتی استفاده می‌شود که اعلان ارائه‌شده توسط ماژول PAM با رشته “Password: ” یا “username's Password: ”. مطابقت داشته باشد. این امر تضمین می‌کند که تنظیم passprompt با احراز هویت به روش چالش-پاسخ تداخلی نداشته باشد. از پرچم passprompt_override می‌توان برای تغییر این رفتار استفاده کرد.

مقدار پیش‌فرض برابر است با ‘[sudo] password for %p: ’.

role

نقش پیش‌فرض SELinux جهت استفاده هنگام ساخت یک زمینه امنیتی جدید برای اجرای دستور. نقش پیش‌فرض را می‌توان به ازای هر دستور در پرونده sudoers یا از طریق گزینه‌های خط فرمان لغو کرد. این گزینه تنها زمانی در دسترس است که sudo با پشتیبانی از SELinux ساخته شده باشد.

runas_default

کاربر پیش‌فرض برای اجرای دستورها در صورتی که گزینه -u در خط فرمان مشخص نشده باشد. پیش‌فرض برابر است با root.

sudoers_locale

محیط محلی (locale) برای تجزیه پرونده sudoers، ثبت وقایع دستورها و ارسال ایمیل. تغییر لوکال ممکن است بر نحوه تفسیر sudoers اثر بگذارد. پیش‌فرض برابر است با ‘C’.

timestamp_type

sudoers از پرونده‌های برچسب زمانی به ازای هر کاربر برای ذخیره موقت اعتبارنامه‌ها استفاده می‌کند. از گزینه timestamp_type می‌توان برای تعیین نوع رکورد برچسب زمانی استفاده کرد. این گزینه مقادیر ممکن زیر را می‌پذیرد:

global

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

ppid

یک رکورد مهر زمانی منفرد برای همه فرایندهایی با شناسه فرایند والد یکسان (معمولاً پوسته) استفاده می‌شود. دستورهای اجراشده از یک پوسته (یا فرایند والد مشترک دیگر) برای مدت timestamp_timeout دقیقه (به‌طور پیش‌فرض ۱۵) به گذرواژه نیاز نخواهند داشت. دستورهای اجراشده از طریق sudo با شناسه فرایند والد متفاوت، برای نمونه از یک اسکریپت پوسته، به‌صورت جداگانه احراز هویت خواهند شد.

tty

یک رکورد مهر زمانی برای هر ترمینال استفاده می‌شود، بدین معنی که نشست‌های ورود کاربر به‌صورت جداگانه احراز هویت می‌شوند. اگر ترمینالی وجود نداشته باشد، رفتار مانند ppid خواهد بود. دستورهای اجراشده از همان ترمینال به مدت timestamp_timeout دقیقه (به‌طور پیش‌فرض ۱۵) به گذرواژه نیاز نخواهند داشت.

kernel

مهر زمانی در هسته به‌عنوان مشخصه دستگاه ترمینال ذخیره می‌شود. اگر ترمینالی وجود نداشته باشد، رفتار مانند ppid خواهد بود. مقدارهای منفی timestamp_timeout پشتیبانی نمی‌شوند و مقدارهای مثبت به حداکثر ۶۰ دقیقه محدود هستند. این قابلیت در حال حاضر فقط روی OpenBSD پشتیبانی می‌شود.

مقدار پیش‌فرض tty است.

این تنظیم فقط در نسخه 1.8.21 یا بالاتر پشتیبانی می‌شود.

timestampdir

دایرکتوری‌ای که در آن sudo فایل‌های مهر زمانی خود را ذخیره می‌کند. این دایرکتوری هنگام راه‌اندازی مجدد سیستم باید پاک شود. پیش‌فرض /run/sudo/ts است.

timestampowner

مالک دایرکتوری وضعیت تذکر، دایرکتوری مهر زمانی و تمامی فایل‌های ذخیره‌شده در آن‌ها. پیش‌فرض root است.

type

نوع پیش‌فرض SELinux هنگام ساخت زمینه امنیتی جدید برای اجرای دستور. نوع پیش‌فرض را می‌توان بر اساس هر دستور در فایل sudoers یا از طریق گزینه‌های خط فرمان بازنویسی کرد. این گزینه تنها زمانی در دسترس است که sudo با پشتیبانی از SELinux ساخته شده باشد.

رشته‌هایی که می‌توانند در زمینه بولی استفاده شوند:

admin_flag

گزینه admin_flag مسیر فایلی را مشخص می‌کند که اولین بار با اجرای sudo توسط کاربری که عضو گروه‌های sudo یا admin است ایجاد می‌شود. تنها در صورتی در دسترس است که sudo با گزینه --enable-admin-flag پیکربندی شده باشد. مقدار پیش‌فرض ~/.sudo_as_admin_successful است.

env_file

گزینه env_file مسیر کامل فایلی شامل متغیرهایی را مشخص می‌کند که باید در محیط برنامه در حال اجرا تنظیم شوند. ورودی‌ها در این فایل باید یا به شکل ‘VARIABLE=value’ یا ‘export VARIABLE=value’ باشند. مقدار می‌تواند به‌صورت اختیاری داخل نقل‌قول تکی یا دوتایی قرار گیرد. متغیرهای این فایل تنها در صورتی اضافه می‌شوند که متغیر از قبل در محیط وجود نداشته باشد. این فایل بخشی از خط‌مشی امنیتی در نظر گرفته می‌شود، محتویات آن مشمول سایر محدودیت‌های محیطی sudo نظیر env_keep و env_check نمی‌گردد.

exempt_group

کاربران این گروه از الزامات گذرواژه و PATH معاف هستند. نام گروه مشخص‌شده نباید شامل پیشوند ‘%’ باشد. این گزینه به‌طور پیش‌فرض تنظیم نشده است.

fdexec

تعیین می‌کند که آیا sudo یک دستور را بر اساس مسیر آن اجرا کند یا از طریق یک توصیف‌کننده پرونده باز. مقدارهای ممکن زیر را می‌پذیرد:

always

همیشه از طریق توصیف‌کننده پرونده اجرا شود.

never

هرگز از طریق توصیف‌کننده پرونده اجرا نشود.

digest_only

تنها در صورتی از طریق توصیف‌کننده پرونده اجرا شود که دستور دارای یک چکیده مرتبط در پرونده sudoers باشد.

مقدار پیش‌فرض digest_only. است. این تنظیم از شرایط رقابتی زمان بررسی تا زمان استفاده هنگامی که دستور در شاخه‌ای با امکان نوشتن توسط کاربر فراخواننده قرار دارد جلوگیری می‌کند.

تنظیم fdexec نخستین عنصر بردار آرگومان را برای اسکریپت‌ها به‌دلیل نحوه اجرای مفسرهای اسکریپت توسط هسته تغییر می‌دهد ($0 در پوسته). به‌جای یک مسیر عادی، به یک توصیف‌کننده پرونده اشاره خواهد کرد. برای نمونه، /dev/fd/4 در سولاریس و /proc/self/fd/4 در لینوکس. یک راه‌حل جایگزین، استفاده از متغیر محیطی SUDO_COMMAND به‌جای آن است.

تنظیم fdexec تنها زمانی استفاده می‌شود که دستور با نام مسیر مطابقت داده شود. اگر دستور با نام مستعار توکار ALL مطابقت یابد، هیچ تاثیری ندارد.

این تنظیم تنها در نسخه 1.8.20 یا بالاتر پشتیبانی می‌شود. اگر سیستم‌عامل از فراخوان سیستمی fexecve(2) پشتیبانی نکند، این تنظیم بی‌اثر خواهد بود.

group_plugin

رشته‌ای شامل یک افزونه گروه sudoers همراه با آرگومان‌های اختیاری. این رشته باید شامل مسیر افزونه، به‌صورت کامل یا نسبی نسبت به شاخه /usr/libexec/sudo باشد، به‌همراه هرگونه آرگومان پیکربندی که افزونه نیاز دارد. این آرگومان‌ها (در صورت وجود) به تابع مقداردهی اولیه افزونه فرستاده می‌شوند. در صورت وجود آرگومان، رشته باید درون جفت‌گیومه قرار گیرد ("").

در سیستم‌های ۶۴ بیتی، اگر افزونه موجود باشد اما بارگذاری نشود، sudoers به‌دنبال نسخه ۶۴ بیتی می‌گردد و در صورت وجود، آن را به‌عنوان جایگزین بارگذاری می‌کند. قوانین دقیق این رفتار بر اساس سیستم متفاوت است. در سولاریس، اگر افزونه در شاخه‌ای ذخیره شده باشد که به “lib”, ختم می‌شود، sudoers مسیر جایگزین را با افزودن “/64” به نام شاخه می‌سازد؛ /usr/lib/group_plugin.so تبدیل می‌شود به /usr/lib/64/group_plugin.so. در لینوکس، شاخه‌ای که به “lib” ختم شود به “lib64” به‌عنوان مسیر جایگزین تبدیل خواهد شد؛ /usr/lib/group_plugin.so تبدیل می‌شود به /usr/lib/64/group_plugin.so. در سایر سیستم‌ها، مسیر جایگزین با افزودن “64” پیش از پسوند پرونده ایجاد می‌شود؛ group_plugin.so تبدیل می‌شود به group_plugin64.so.

برای اطلاعات بیشتر ببینید: GROUP PROVIDER PLUGINS.

lecture

این گزینه کنترل می‌کند چه زمانی یک پیام کوتاه در کنار اعلان گذرواژه چاپ شود. مقدارهای ممکن زیر را می‌پذیرد:

always

همیشه به کاربر تذکر داده شود.

never

هرگز به کاربر تذکر داده نشود.

once

تنها نخستین باری که کاربر sudo را اجرا می‌کند به او تذکر داده شود.

اگر مقداری تعیین نشود، مقدار once ضمنی خواهد بود. نفی این گزینه منجر به استفاده از مقدار never می‌شود. مقدار پیش‌گزیده never است.

lecture_file

مسیر پرونده‌ای شامل متن تذکر جایگزین برای sudo که در صورت وجود پرونده نام‌برده، به جای تذکر استاندارد استفاده می‌شود. به‌طور پیش‌گزیده، sudo از یک تذکر توکار استفاده می‌کند.

listpw

این گزینه زمان نیاز به گذرواژه هنگام اجرای sudo توسط کاربر به همراه گزینه -l را کنترل می‌کند. مقدارهای ممکن آن عبارتند از:

all

تمام مدخل‌های پرونده sudoers کاربر برای میزبان فعلی باید دارای پرچم NOPASSWD باشند تا نیازی به وارد کردن گذرواژه نباشد.

always

کاربر برای استفاده از گزینه -l باید همیشه گذرواژه را وارد کند.

any

حداقل یکی از مدخل‌های پرونده sudoers کاربر برای میزبان فعلی باید دارای پرچم NOPASSWD باشد تا نیازی به وارد کردن گذرواژه نباشد.

never

کاربر برای استفاده از گزینه -l هرگز نیازی به وارد کردن گذرواژه ندارد.

اگر مقداری تعیین نشود، مقدار any ضمنی خواهد بود. نفی این گزینه منجر به استفاده از مقدار never می‌شود. مقدار پیش‌گزیده any است.

log_format

قالب ثبت وقایع. قالب‌های وقایع پشتیبانی‌شده عبارتند از:

json

ثبت وقایع در قالب JSON. مدخل‌های گزارش JSON در صورت مجاز بودن دستور، شامل جزئیات کامل کاربر و محیط اجرا هستند. به دلیل محدودیت‌های پروتکل، وقایع JSON ارسال‌شده از طریق syslog ممکن است کوتاه شوند.

sudo

گزارش‌های سنتی به سبک sudo؛ برای توضیحات مربوط به قالب پرونده گزارش به EVENT LOGGING مراجعه کنید.

این تنظیم بر گزارش‌های ارسال‌شده از طریق syslog(3) و همچنین بر پرونده مشخص‌شده توسط تنظیم logfile (در صورت وجود) اثر می‌گذارد. مقدار پیش‌گزیده sudo است.

logfile

مسیر پرونده ثبت وقایع sudo (نه پرونده ثبت وقایع syslog). تنظیم یک مسیر، ثبت در پرونده را فعال می‌کند؛ نفی این گزینه آن را غیرفعال می‌سازد. به‌طور پیش‌گزیده، sudo وقایع را از طریق syslog ثبت می‌کند.

mailerflags

پرچم‌هایی که هنگام فراخوانی میلر استفاده می‌شوند. پیش‌فرض: -t.

mailerpath

مسیر برنامهٔ ارسال ایمیل برای فرستادن هشدارهای ایمیلی (جهت جلوگیری از ارسال ایمیل توسط sudo نفی شود). پیش‌فرض مسیر sendmail در زمان پیکربندی و ساخت است.

mailfrom

نشانی مورد استفاده در بخش “from” هنگام ارسال ایمیل‌های خطا و هشدار. برای جلوگیری از تفسیر علامت ‘@’ توسط sudo ، نشانی باید در گیومه دوتایی ("") قرار گیرد. پیش‌فرض نام کاربری است که sudo را اجرا کرده است.

mailto

نشانی مقصد برای ارسال ایمیل‌های خطا و هشدار (جهت جلوگیری از ارسال ایمیل توسط sudo نفی شود). برای جلوگیری از تفسیر علامت ‘@’ توسط sudo ، نشانی باید در گیومه دوتایی ("") قرار گیرد. پیش‌فرض root است.

rlimit_as

حداکثر اندازهٔ مجاز برای رشد فضای آدرس فرایند (به بایت)، در صورت پشتیبانی توسط سیستم‌عامل. برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_core

حداکثر اندازهٔ مجاز برای ایجاد پروندهٔ core dump (به بایت). برای اطلاعات بیشتر به Resource limits مراجعه کنید. پیش‌فرض 0 است (هیچ core dumpای ایجاد نمی‌شود).

rlimit_cpu

حداکثر زمان پردازنده که فرایند مجاز به مصرف آن است (به ثانیه). برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_data

حداکثر اندازهٔ بخش داده‌ها (data segment) برای فرایند (به بایت). برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_fsize

حداکثر اندازهٔ پرونده‌ای که فرایند مجاز به ایجاد آن است (به بایت). برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_locks

حداکثر تعداد قفل‌هایی که فرایند مجاز به برقراری آن است، در صورت پشتیبانی توسط سیستم‌عامل. برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_memlock

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

rlimit_nofile

حداکثر تعداد پرونده‌هایی که فرایند مجاز به باز نگه داشتن آن‌ها است. برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_nproc

حداکثر تعداد فرایندهایی که کاربر مجاز به اجرای هم‌زمان آن‌ها است. برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_rss

حداکثر اندازه‌ای که اندازهٔ مقیم در حافظه (resident set size) فرایند می‌تواند رشد کند (به بایت). برای اطلاعات بیشتر به Resource limits مراجعه کنید.

rlimit_stack

حداکثر اندازه‌ای که پشتهٔ فرایند می‌تواند رشد کند (به بایت). برای اطلاعات بیشتر به Resource limits مراجعه کنید.

restricted_env_file

گزینهٔ restricted_env_file مسیر کامل فایلی را مشخص می‌کند که شامل متغیرهایی است که باید در محیط برنامهٔ در حال اجرا مقداردهی شوند. ورودی‌های این فایل باید به شکل ‘VARIABLE=value’ یا ‘export VARIABLE=value’. باشند. مقدار می‌تواند به صورت اختیاری درون کوتیشن تکی یا جفتی قرار گیرد. متغیرهای این فایل تنها در صورتی اضافه می‌شوند که متغیر از قبل در محیط وجود نداشته باشد. برخلاف env_file ، محتوای این فایل مورد اعتماد نیست و به روشی مشابه محیط کاربر فراخواننده پردازش می‌شود. اگر env_reset فعال باشد، متغیرهای فایل تنها در صورتی اضافه می‌شوند که با یکی از فهرست‌های env_check یا env_keep همخوانی داشته باشند. اگر env_reset غیرفعال باشد، متغیرهای درون فایل تا زمانی که با فهرست env_delete مطابقت نداشته باشند، اضافه خواهند شد. در هر دو حالت، محتوای restricted_env_file پیش از محتوای env_file پردازش می‌شود.

runchroot

در صورت تنظیم، sudo از این مقدار به عنوان دایرکتوری ریشه هنگام اجرای دستور استفاده می‌کند. مقدار ویژهٔ “*” به کاربر اجازه می‌دهد تا دایرکتوری ریشه را از طریق گزینهٔ -R در sudo مشخص کند. برای جزئیات بیشتر بخش Chroot_Spec را ببینید.

تنها در صورتی می‌توان از runchroot به عنوان تنظیم Defaults ویژهٔ دستور استفاده کرد که دستور با مسیر یکسان هم در داخل و هم خارج از محیط chroot وجود داشته باشد. این محدودیت برای تنظیمات Defaults سراسری، میزبان یا مبتنی بر کاربر یا برای یک Cmnd_Spec که شامل Chroot_Spec باشد، اعمال نمی‌شود.

این تنظیم فقط در نسخهٔ 1.9.3 یا بالاتر پشتیبانی می‌شود.

runcwd

در صورت تنظیم، sudo از این مقدار به عنوان دایرکتوری کاری هنگام اجرای دستور استفاده خواهد کرد. مقدار ویژهٔ “*” به کاربر اجازه می‌دهد دایرکتوری کاری را از طریق گزینهٔ -D در sudo مشخص کند. برای جزئیات بیشتر بخش Chdir_Spec را ببینید.

این تنظیم فقط در نسخهٔ 1.9.3 یا بالاتر پشتیبانی می‌شود.

secure_path

در صورت تنظیم، sudo از این مقدار به جای متغیر محیطیِ PATH کاربر استفاده خواهد کرد. این گزینه می‌تواند برای بازنشانی PATH به یک مقدار معتبر و شناخته‌شده شامل دایرکتوری‌های دستورات مدیر سیستم مانند /usr/sbin استفاده شود.

کاربران حاضر در گروه مشخص‌شده توسط گزینهٔ exempt_group تحت تأثیر secure_path قرار نمی‌گیرند. این گزینه به صورت پیش‌فرض تنظیم نشده است.

syslog

فسیلیتی Syslog در صورتی که از syslog برای ثبت وقایع استفاده می‌شود (نفی شود تا ثبت وقایع syslog غیرفعال گردد). پیش‌فرض authpriv است.

تسهیلات syslog زیر پشتیبانی می‌شوند: authpriv (اگر سیستم‌عامل شما از آن پشتیبانی کند)، auth, daemon, user, local0, local1, local2, local3, local4, local5, local6, و local7.

syslog_badpri

اولویت syslog مورد استفاده هنگامی که کاربر مجاز به اجرای دستور نیست یا هنگامی که احراز هویت ناموفق است. پیش‌فرض alert است.

اولویت‌های syslog زیر پشتیبانی می‌شوند: alert, crit, debug, emerg, err, info, notice, warning, و none. نفی این گزینه یا تنظیم مقدار آن به none ثبت گزارش دستورهای ناموفق را غیرفعال می‌کند.

syslog_goodpri

اولویت syslog مورد استفاده هنگامی که کاربر مجاز به اجرای دستور است و احراز هویت موفقیت‌آمیز است. پیش‌فرض notice است.

برای فهرست اولویت‌های syslog پشتیبانی‌شده به syslog_badpri مراجعه کنید. نفی این گزینه یا تنظیم مقدار آن به none ثبت گزارش دستورهای موفق را غیرفعال می‌کند.

verifypw

این گزینه مشخص می‌کند چه زمانی هنگام اجرای sudo توسط کاربر با گزینهٔ -v نیاز به وارد کردن گذرواژه خواهد بود. مقدارهای ممکن آن عبارتند از:

all

تمام ورودی‌های کاربر در پروندهٔ sudoers برای میزبان فعلی باید دارای پرچم NOPASSWD باشند تا از وارد کردن گذرواژه صرف‌نظر شود.

always

کاربر برای استفاده از گزینهٔ -v همواره باید گذرواژه وارد کند.

any

حداقل یکی از ورودی‌های کاربر در پروندهٔ sudoers برای میزبان فعلی باید دارای پرچم NOPASSWD باشد تا از وارد کردن گذرواژه صرف‌نظر شود.

never

کاربر برای استفاده از گزینهٔ -v هرگز نیازی به وارد کردن گذرواژه ندارد.

اگر مقداری مشخص نشود، مقدار all ضمنی فرض می‌شود. نفی این گزینه موجب استفاده از مقدار never می‌شود. مقدار پیش‌فرض عبارت است از all.

فهرست‌هایی که می‌توان در سیاق بولی استفاده کرد:

env_check

متغیرهای محیطی که باید از محیط کاربر حذف شوند مگر اینکه “امن”. در نظر گرفته شوند. برای تمام متغیرها به‌جز TZ, “امن” بدین معنی است که مقدار متغیر شامل هیچ‌یک از نویسه‌های ‘%’ یا ‘/’ نباشد. این قابلیت می‌تواند برای محافظت در برابر آسیب‌پذیری‌های قالب‌بندی سبک printf در برنامه‌های ضعیف نوشته‌شده استفاده شود. متغیر TZ در صورت برقراری هر یک از موارد زیر ناامن در نظر گرفته می‌شود:

• از یک نام مسیر کامل تشکیل شده باشد، که به‌صورت اختیاری با دونقطه (‘:’), آغاز شده و با مکان دایرکتوری zoneinfo مطابقت نداشته باشد.
• شامل جزء مسیر .. باشد.
• شامل فاصله یا نویسه‌های غیرقابل چاپ باشد.
• طولانی‌تر از مقدار PATH_MAX. باشد.

آرگومان می‌تواند یک فهرست جداشده با فاصله درون گیومه یا یک مقدار تکی بدون گیومه باشد. این فهرست می‌تواند به ترتیب با استفاده از عملگرهای ‘=’, ‘+=’, ‘-=’, و ‘!’ جایگزین، افزوده، حذف یا غیرفعال شود. صرف‌نظر از اینکه گزینهٔ env_reset فعال یا غیرفعال باشد، متغیرهای مشخص‌شده توسط env_check در صورت قبولی در بررسی فوق، در محیط حفظ خواهند شد. فهرست سراسری متغیرهای محیطی جهت بررسی زمانی نمایش داده می‌شود که sudo توسط root همراه با گزینهٔ -V اجرا شود.

env_delete

متغیرهای محیطی که باید از محیط کاربر حذف شوند هنگامی که گزینهٔ env_reset در حال اجرا نیست. آرگومان می‌تواند یک فهرست جداشده با فاصله درون گیومه یا یک مقدار تکی بدون گیومه باشد. این فهرست می‌تواند به ترتیب با استفاده از عملگرهای ‘=’, ‘+=’, ‘-=’, و ‘!’ جایگزین، افزوده، حذف یا غیرفعال شود. فهرست سراسری متغیرهای محیطی جهت حذف زمانی نمایش داده می‌شود که sudo توسط root همراه با گزینهٔ -V اجرا شود. بسیاری از سیستم‌عامل‌ها متغیرهای بالقوه خطرناک را از محیط هر فرایند set-user-ID (مانند sudo). حذف خواهند کرد.

env_keep

متغیرهای محیطی که هنگام فعال بودن گزینهٔ env_reset در محیط کاربر حفظ می‌شوند. این گزینه امکان کنترل دقیق بر روی محیطی که فرایندهای ایجادشده توسط sudo-spawned دریافت خواهند کرد را فراهم می‌کند. آرگومان می‌تواند یک فهرست جداشده با فاصله درون گیومه دوگانه یا یک مقدار واحد بدون گیومه دوگانه باشد. این فهرست می‌تواند به‌ترتیب با استفاده از عملگرهای ‘=’, ‘+=’, ‘-=’, و ‘!’ جایگزین شود، به آن افزوده شود، از آن حذف شود یا غیرفعال گردد. فهرست سراسری متغیرهایی که باید حفظ شوند، هنگام اجرای sudo توسط root همراه با گزینهٔ -V نمایش داده می‌شود.

حفظ متغیر محیطی HOME دارای پیامدهای امنیتی است، زیرا بسیاری از برنامه‌ها هنگام جستجو برای فایل‌های پیکربندی یا داده از آن استفاده می‌کنند. افزودن HOME به env_keep ممکن است به کاربر امکان اجرای دستورات نامحدود از طریق sudo را بدهد و اکیداً منع می‌شود. کاربرانی که مایل به ویرایش فایل‌ها با sudo هستند باید به‌جای فراخوانی مستقیم ویرایشگر، sudoedit (یا sudo -e) را اجرا کنند تا به پیکربندی معمول ویرایشگر خود دسترسی داشته باشند.

log_servers

فهرستی از یک یا چند سرور برای استفاده در ذخیره‌سازی راه‌دور گزارش رویداد و I/O، جداشده با فاصله. سرورهای گزارش باید در حال اجرای sudo_logsrvd یا سرویس دیگری باشند که پروتکل شرح‌داده‌شده در sudo_logsrv.proto(5). را پیاده‌سازی می‌کند.

نشانی‌های سرور باید به شکل “host[:port][(tls)]”. باشند. بخش میزبان می‌تواند یک نام میزبان، یک نشانی IPv4 یا یک نشانی IPv6 درون براکت باشد.

اگر پرچم اختیاری tls وجود داشته باشد، اتصال با امنیت لایهٔ انتقال (TLS) نسخهٔ 1.2 یا 1.3 ایمن خواهد شد. نسخه‌های پیش از 1.2 پروتکل TLS پشتیبانی نمی‌شوند.

در صورت تعیین پورت، این مقدار می‌تواند یک شماره پورت یا یک نام سرویس شناخته‌شده طبق تعریف پایگاه‌دادهٔ نام سرویس‌های سیستم باشد. در صورت عدم تعیین پورت، از پورت 30343 برای اتصال‌های متنی ساده و از پورت 30344 برای اتصال‌های TLS استفاده خواهد شد.

هنگام تنظیم log_servers ، داده‌های گزارش رویداد هم به‌صورت محلی (تنظیمات syslog و log_file را ببینید) و هم از راه دور ثبت می‌شوند، اما داده‌های گزارش I/O فقط از راه دور ثبت خواهند شد. در صورت تعیین چندین میزبان، تلاش برای برقراری اتصال به آن‌ها به ترتیب معکوس انجام می‌شود. اگر هیچ سرور گزارشی در دسترس نباشد، کاربر قادر به اجرای دستور نخواهد بود مگر اینکه پرچم ignore_iolog_errors (در صورت فعال بودن گزارش‌گیری I/O) یا پرچم ignore_log_errors (در صورت غیرفعال بودن گزارش‌گیری I/O) تنظیم شده باشد. به همین ترتیب، اگر اتصال به سرور گزارش در حین اجرای sudo قطع شود، دستور متوقف خواهد شد مگر اینکه پرچم ignore_iolog_errors (در صورت فعال بودن گزارش‌گیری I/O) یا پرچم ignore_log_errors (در صورت غیرفعال بودن گزارش‌گیری I/O) تنظیم شده باشد.

این تنظیم فقط در نسخهٔ 1.9.0 یا بالاتر پشتیبانی می‌شود.

passprompt_regex

فهرستی از عبارت‌های باقاعده گسترده POSIX برای تطبیق اعلان‌های گذرواژه در خروجی پایانه. به‌عنوان یک قابلیت افزوده، اگر عبارت باقاعده با “(?i)”, آغاز شود، تطبیق بدون حساسیت به بزرگی و کوچکی حروف انجام می‌شود. طول هر عبارت باقاعده به ۱۰۲۴ نویسه محدود است. این گزینه تنها زمانی استفاده می‌شود که log_passwords غیرفعال شده باشد. مقدار پیش‌فرض: “[Pp]assword[: ]*”

این تنظیم فقط در نگارش 1.9.10 یا بالاتر پشتیبانی می‌شود.

ورودی‌های لاگ دستورهای پذیرفته‌شده

دستورهایی که sudo اجرا می‌کند با قالب زیر ثبت می‌شوند (برای خوانایی به چند سطر تقسیم شده است):

date hostname progname: username : TTY=ttyname ; CHROOT=chroot ; \
    PWD=cwd ; USER=runasuser ; GROUP=runasgroup ; TSID=logid ; \
    ENV=env_vars COMMAND=command

فیلدها به شرح زیر هستند:

date

تاریخ اجرای دستور. معمولاً در این قالب است: “MMM, DD, HH:MM:SS”. در صورت ثبت وقایع از طریق syslog(3), قالب واقعی تاریخ توسط دیمن syslog کنترل می‌شود. اگر لاگ در یک پرونده ذخیره شود و گزینه log_year فعال باشد، تاریخ شامل سال نیز خواهد بود.

hostname

نام میزبانی که sudo روی آن اجرا شده است. این فیلد تنها هنگام ثبت وقایع از طریق syslog(3). وجود دارد.

progname

نام برنامه، معمولاً sudo یا sudoedit. این فیلد تنها هنگام ثبت وقایع از طریق syslog(3). وجود دارد.

username

نام کاربری کاربری که sudo. را اجرا کرده است.

ttyname

نام کوتاه ترمینال (برای نمونه “console”, “tty01”, یا “pts/0”) که sudo روی آن اجرا شده است، یا “unknown” اگر هیچ ترمینالی وجود نداشته باشد.

chroot

شاخه ریشه (root) که دستور در آن اجرا شده است، در صورت تعیین شدن.

cwd

شاخه کاری فعلی که sudo در آن اجرا شده است.

runasuser

کاربری که دستور با هویت او اجرا شده است.

runasgroup

گروهی که دستور با هویت آن اجرا شده است، در صورتی که در خط فرمان مشخص شده باشد.

logid

یک شناسه لاگ I/O که می‌تواند برای بازپخش خروجی دستور به کار رود. این فیلد تنها زمانی وجود دارد که گزینه log_input یا log_output فعال باشد.

env_vars

فهرستی از متغیرهای محیطی مشخص‌شده در خط فرمان، در صورت تعیین شدن.

command

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

پیام‌ها با استفاده از لوکال تعیین‌شده توسط sudoers_locale ثبت می‌شوند، که مقدار پیش‌فرض آن لوکال ‘C’ است.

ورودی‌های لاگ دستورهای ردشده

اگر کاربر مجاز به اجرای دستور نباشد، دلیل رد شدن پس از نام کاربری می‌آید. دلایل احتمالی عبارتند از:

user NOT in sudoers

نام کاربر در پروندهٔ sudoers وجود ندارد.

user NOT authorized on host

نام کاربر در پروندهٔ sudoers آمده است ولی مجاز به اجرای دستورها روی این میزبان نیست.

command not allowed

نام کاربر در پروندهٔ sudoers برای این میزبان آمده است، اما مجاز به اجرای دستور مشخص‌شده نیست.

3 incorrect password attempts

کاربر پس از ۳ بار تلاش موفق به وارد کردن گذرواژه نشد. تعداد تلاش‌های واقعی بر اساس تعداد دفعات ناموفق و مقدار گزینهٔ passwd_tries متغیر خواهد بود.

a password is required

گزینهٔ -n مشخص شده بود ولی به گذرواژه نیاز بود.

sorry, you are not allowed to set the following environment variables

کاربر در خط فرمان متغیرهای محیطی‌ای را مشخص کرده که توسط sudoers مجاز شناخته نشده‌اند.

ورودی‌های لاگ خطا

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

parse error in /etc/sudoers near line N

sudoers هنگام تجزیهٔ پروندهٔ مشخص‌شده با خطا مواجه شد. در برخی موارد، بسته به نوع خطا ممکن است خطای واقعی یک خط بالاتر یا پایین‌تر از شماره خط ذکرشده باشد.

problem with defaults entries

پروندهٔ sudoers شامل یک یا چند تنظیم ناشناختهٔ Defaults است. این موضوع مانع اجرای sudo نمی‌شود، اما پروندهٔ sudoers باید با استفاده از visudo بررسی شود.

timestamp owner (username): No such user

مالک شاخهٔ مُهر زمانی، همان‌طور که توسط تنظیم timestampowner مشخص شده است، در پایگاه‌دادهٔ گذرواژه یافت نشد.

unable to open/read /etc/sudoers

پروندهٔ sudoers برای خواندن باز نشد. این حالت زمانی رخ می‌دهد که پروندهٔ sudoers روی یک سامانه پروندهٔ ریموت قرار دارد که user-ID 0 را به مقدار دیگری نگاشت می‌کند. به‌طور معمول، sudoers تلاش می‌کند پروندهٔ sudoers را با استفاده از مجوزهای گروه باز کند تا از این مشکل جلوگیری کند. مالکیت /etc/sudoers را تغییر دهید یا آرگومانی مانند “sudoers_uid=N” (که در آن ‘N’ همان user-ID مالک پروندهٔ sudoers است) را به انتهای خط sudoers Plugin در پروندهٔ sudo.conf(5) اضافه کنید.

unable to open /etc/sudoers

پروندهٔ /etc/sudoers وجود ندارد.

/etc/sudoers is not a regular file

پروندهٔ /etc/sudoers وجود دارد ولی یک پروندهٔ معمولی یا پیوند نمادین نیست.

/etc/sudoers is owned by uid N, should be 0

پروندهٔ sudoers مالک نادرستی دارد. اگر می‌خواهید مالک پروندهٔ sudoers را تغییر دهید، “sudoers_uid=N” (که در آن ‘N’ شناسهٔ کاربری مالک پروندهٔ sudoers است) را به خط sudoers Plugin در پروندهٔ sudo.conf(5) بیفزایید.

/etc/sudoers is world writable

مجوزهای پروندهٔ sudoers به همهٔ کاربران اجازهٔ نوشتن در آن را می‌دهد. پروندهٔ sudoers نباید همگانی‌نوشتنی باشد، حالت پیش‌گزیدهٔ پرونده 0440 است (خواندنی برای مالک و گروه، بدون اجازهٔ نوشتن برای هیچ‌کس). حالت پیش‌گزیده می‌تواند از طریق گزینهٔ “sudoers_mode” در خط sudoers Plugin در پروندهٔ sudo.conf(5) تغییر کند.

/etc/sudoers is owned by gid N, should be 1

پروندهٔ sudoers مالکیت گروهی نادرستی دارد. اگر می‌خواهید مالکیت گروهی پروندهٔ sudoers را تغییر دهید، “sudoers_gid=N” (که در آن ‘N’ شناسهٔ گروهی مالک پروندهٔ sudoers است) را به خط sudoers Plugin در پروندهٔ sudo.conf(5) بیفزایید.

unable to open /run/sudo/ts/username

sudoers نتوانست پروندهٔ برچسب زمان کاربر را بخواند یا ایجاد کند. این وضعیت زمانی رخ می‌دهد که timestampowner روی کاربری غیر از root تنظیم شده باشد و حالت دسترسی /run/sudo برای گروه یا دیگران قابل جست‌وجو نباشد. حالت پیش‌گزیده برای /run/sudo 0711 است.

unable to write to /run/sudo/ts/username

sudoers نتوانست در پروندهٔ برچسب زمان کاربر بنویسد.

/run/sudo/ts is owned by uid X, should be Y

شاخهٔ برچسب زمان متعلق به کاربری غیر از timestampowner. است. این وضعیت زمانی رخ می‌دهد که مقدار timestampowner تغییر کرده باشد. sudoers شاخهٔ برچسب زمان را تا زمان تصحیح مالک نادیده خواهد گرفت.

/run/sudo/ts is group writable

شاخهٔ برچسب زمان برای گروه نوشتنی است؛ این شاخه تنها باید توسط timestampowner. نوشتنی باشد. حالت پیش‌گزیده برای شاخهٔ برچسب زمان 0700 است. sudoers شاخهٔ برچسب زمان را تا زمان تصحیح حالت دسترسی نادیده خواهد گرفت.

نکاتی درباره ثبت وقایع از طریق syslog

به‌طور پیش‌فرض، ثبت وقایع توسط sudoers انجام می‌شود از طریق syslog(3). فیلدهای date, hostname, و progname توسط تابع syslog(3) سیستم افزوده می‌شوند، نه توسط خود sudoers به‌تنهایی. از این رو، قالب آن‌ها ممکن است در سیستم‌های گوناگون متفاوت باشد.

بیشینه اندازه پیام‌های syslog از سیستمی به سیستم دیگر متفاوت است. از تنظیم syslog_maxlen می‌توان برای تغییر بیشینه اندازه پیام syslog از مقدار پیش‌فرض ۹۸۰ بایت استفاده کرد. برای اطلاعات بیشتر، رجوع کنید به توضیحات syslog_maxlen.

نکاتی درباره ثبت وقایع در پرونده

اگر گزینه logfile تنظیم شده باشد، sudoers وقایع را در پرونده‌ای محلی ثبت می‌کند، مانند /var/log/sudo. هنگام ثبت در پرونده، sudoers قالبی را به کار می‌برد مشابه با syslog(3), همراه با چند تفاوت مهم:

1. فیلد progname وجود ندارد.
2. hostname تنها در صورتی ثبت می‌شود که گزینه log_host فعال باشد.
3. تاریخ شامل سال نمی‌شود، مگر اینکه گزینه log_year فعال باشد.
4. خطوطی که طولانی‌تر از loglinelen نویسه (به‌طور پیش‌فرض ۸۰) باشند، شکسته شده و در خط بعدی با ۴ نویسه تورفتگی ادامه می‌یابند. این امر خواندن مدخل‌ها را برای انسان آسان‌تر می‌کند، اما استفاده از grep(1) روی پرونده‌های گزارش را دشوارتر می‌سازد. اگر گزینه loglinelen روی 0 تنظیم شود (یا نفی شود با ‘!’), شکستن خطوط غیرفعال خواهد شد.

دام‌های ثبت ورودی/خروجی

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

#!/bin/sh
sudo echo testing
echo done

اگر اسکریپت به عنوان آرگومان به پوسته داده شود، طبق انتظار عمل خواهد کرد:

$ sh test.sh
testing
done

اما اگر اسکریپت از طریق ورودی استاندارد به شل داده شود، دستور ‘sudo echo testing’ باقی‌مانده اسکریپت را مصرف خواهد کرد. این بدان معناست که عبارت ‘echo done’ هرگز اجرا نمی‌شود.

$ sh -s < test.sh
testing

چندین راه برای دور زدن این مشکل وجود دارد:

1. تغییر مسیر ورودی استاندارد از /dev/null هنگام اجرای دستوری با sudo که نیازی به خواندن ورودی استاندارد ندارد.

   sudo echo testing < /dev/null

2. ارسال اسکریپت به شل با نام مسیر به‌جای ورودی استاندارد.

   sh test.sh

3. غیرفعال‌سازی ثبت لاگ ورودی استاندارد برای دستوراتی که نیازی به خواندن ورودی استاندارد ندارند.

   Defaults!/bin/echo !log_stdin

بسته به دستور، ممکن است ثبت لاگ ورودی استاندارد یا خروجی استاندارد مطلوب نباشد. به عنوان مثال، ثبت لاگ I/O دستوراتی که حجم زیادی از داده را از طریق خروجی استاندارد یا ورودی استاندارد ارسال یا دریافت می‌کنند مانند rsync(1) و tar(1) می‌تواند فایل‌سیستم لاگ را با داده‌های زائد پر کند. غیرفعال کردن ثبت لاگ ورودی استاندارد و خروجی استاندارد برای چنین دستوراتی به صورت زیر امکان‌پذیر است:

Cmnd_Alias COPY_CMDS = /usr/bin/tar, /usr/bin/cpio, /usr/bin/rsync

# Log input and output but omit stdin and stdout when copying files.
Defaults log_input, log_output
Defaults!COPY_CMDS !log_stdin, !log_stdout

با این حال، توجه داشته باشید که استفاده از فلگ log_input یا تگ دستور LOG_INPUT همچنین log_stdin. را فعال خواهد کرد. به همین ترتیب، فلگ log_ouput یا تگ دستور LOG_OUTPUT موجب فعال‌سازی log_stdout و log_stderr. خواهد شد. ترتیب دقیق قوانین ممکن است برای رسیدن به نتایج مورد انتظار شما ضروری باشد.

قالب لاگ ورودی/خروجی (I/O)

برای هر دو لاگ I/O محلی و راه دور، هر لاگ در یک دایرکتوری جداگانه حاوی پرونده‌های زیر ذخیره می‌شود:

log

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

log.json

یک پرونده با ساختار JSON شامل اطلاعات مربوط به دستور. این پرونده مشابه پرونده log است، اما حاوی اطلاعات بیشتری بوده و به‌سادگی قابل گسترش است. در صورت وجود، پرونده log.json توسط sudoreplay(8) با اولویت نسبت به پرونده log استفاده خواهد شد. این پرونده ممکن است شامل مؤلفه‌های زیر باشد:

timestamp

یک شیء JSON حاوی زمان اجرای دستور. این مؤلفه شامل دو مقدار است: seconds و nanoseconds.

columns

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

command

مسیر کامل دستوری که اجرا شده است.

lines

تعداد سطرهای ترمینالی که دستور روی آن اجرا شده است، یا صفر در صورتی که ترمینالی وجود نداشته باشد.

runargv

یک آرایه JSON نشان‌دهنده بردار آرگومان‌های دستور، به همان صورتی که به فراخوان سیستمی execve(2) ارسال شده است.

runenv

یک آرایه JSON نشان‌دهنده متغیرهای محیطی دستور، به همان صورتی که به فراخوان سیستمی execve(2) ارسال شده است.

rungid

شناسه گروهی (GID) که دستور با آن اجرا شده است. این مؤلفه تنها زمانی وجود دارد که کاربر گروهی را در خط فرمان مشخص کرده باشد.

rungroup

نام گروهی که دستور با آن اجرا شده است. این مؤلفه تنها زمانی وجود دارد که کاربر گروهی را در خط فرمان مشخص کرده باشد.

runuid

شناسه کاربری (UID) که دستور با آن اجرا شده است.

runuser

نام کاربری که دستور با آن اجرا شده است.

submitcwd

شاخه کاری جاری در زمانی که sudo اجرا شد.

submithost

نام میزبانی که دستور روی آن اجرا شده است.

submituser

نام کاربری که دستور را از طریق sudo. اجرا کرده است.

ttyname

مسیر ترمینالی که کاربر sudo را از آن فراخوانی کرده است. اگر دستور در یک شبه‌ترمینال اجرا شده باشد، ttyname با ترمینالی که دستور واقعاً در آن اجرا شده است متفاوت خواهد بود.

timing

اطلاعات زمان‌بندی مورد استفاده برای بازپخش نشست. هر خط شامل نوع مدخل لاگ I/O و مقدار زمان سپری‌شده از مدخل پیشین، به‌همراه داده‌های اختصاصی آن نوع است. انواع مدخل‌های لاگ I/O و داده‌های اختصاصی متناظر با آن‌ها عبارتند از:

0

ورودی استاندارد، تعداد بایت‌ها در مدخل

1

خروجی استاندارد، تعداد بایت‌ها در مدخل

2

خطای استاندارد، تعداد بایت‌ها در مدخل

3

ورودی ترمینال، تعداد بایت‌ها در مدخل

4

خروجی ترمینال، تعداد بایت‌ها در مدخل

5

تغییر اندازه پنجره، تعداد سطرهای جدید و ستون‌ها

6

سازگاری با اشکال خروجی ترمینال در sudo 1.8.7

7

تعلیق یا ازسرگیری دستور، سیگنال دریافت‌شده

ttyin

ورودی خام از پایانهٔ کاربر، دقیقاً به همان صورت که دریافت شده است. این پرونده تنها در صورتی وجود دارد که پرچم‌های log_input یا log_ttyin تنظیم شده باشند و sudo از یک پایانه اجرا شده باشد. هیچ پس‌پردازشی انجام نمی‌شود. برای مشاهدهٔ دستی، ممکن است بخواهید نویسه‌های بازگشت به ابتدای سطر (CR) را در گزارش به خط جدید (LF) تبدیل کنید. برای نمونه: ‘gunzip -c ttyin | tr "\r" "\n"’

stdin

ورودی استاندارد هنگامی که هیچ پایانه‌ای وجود ندارد، یا ورودی تغییرمسیریافته از یک لوله یا پرونده. این پرونده تنها در صورتی وجود دارد که پرچم‌های log_input یا log_stdin تنظیم شده باشند و ورودی استاندارد به یک پایانه متصل نباشد.

ttyout

خروجی از شبه‌پایانه (آنچه دستور روی صفحه می‌نویسد). پیش از ثبت داده‌ها، پس‌پردازش ویژهٔ پایانه انجام می‌شود. این بدان معناست که برای نمونه، خطوط جدید معمولاً به جفت‌های خط جدید/بازگشت به ابتدای سطر تبدیل می‌شوند و تب‌ها ممکن است به فاصله گسترش یابند. این پرونده تنها در صورتی وجود دارد که پرچم‌های log_output یا log_ttyout تنظیم شده باشند و sudo از یک پایانه اجرا شده باشد.

stdout

خروجی استاندارد هنگامی که هیچ پایانه‌ای وجود ندارد، یا خروجی تغییرمسیریافته به یک لوله یا پرونده. این پرونده تنها در صورتی وجود دارد که پرچم‌های log_output یا log_stdout تنظیم شده باشند و خروجی استاندارد به یک پایانه متصل نباشد.

stderr

خطای استاندارد هنگامی که هیچ پایانه‌ای وجود ندارد، یا خروجی تغییرمسیریافته به یک لوله یا پرونده. این پرونده تنها در صورتی وجود دارد که پرچم‌های log_output یا log_stderr تنظیم شده باشند و خطای استاندارد به یک پایانه متصل نباشد.

تمام پرونده‌ها به جز log با قالب gzip فشرده می‌شوند، مگر اینکه پرچم compress_io غیرفعال شده باشد. به‌دلیل میان‌گیری (buffering)، معمولاً امکان نمایش بی‌درنگ گزارش‌های I/O در حین اجرای برنامه وجود ندارد. داده‌های گزارش I/O تا زمانی که برنامهٔ اجراشده توسط sudo خارج نشود یا با یک سیگنال متوقف نگردد، کامل نخواهد بود. از پرچم iolog_flush می‌توان برای غیرفعال کردن میان‌گیری استفاده کرد، که در این حالت داده‌های گزارش I/O به‌محض در دسترس قرار گرفتن روی دیسک نوشته می‌شوند. بخش خروجی یک پروندهٔ گزارش I/O را می‌توان با ابزار sudoreplay(8) مشاهده کرد، که از آن می‌توان برای فهرست کردن یا جستجوی گزارش‌های موجود نیز استفاده نمود.

ورودی کاربر ممکن است حاوی اطلاعات حساسی مانند گذرواژه‌ها باشد (حتی اگر روی صفحه نمایش داده نشوند)، که به‌صورت رمزنشده در پروندهٔ گزارش ذخیره خواهند شد. در بیشتر موارد، ثبت خروجی دستور از طریق log_output یا LOG_OUTPUT تنها چیزی است که نیاز خواهد بود. هنگام ثبت گزارش ورودی، غیرفعال کردن پرچم log_passwords را در نظر داشته باشید.

از آنجا که گزارش‌های I/O مربوط به هر نشست در شاخه‌ای جداگانه ذخیره می‌شوند، نمی‌توان از ابزارهای سنتی چرخش لاگ برای محدود کردن تعداد گزارش‌های I/O استفاده کرد. ساده‌ترین راه برای محدود کردن تعداد I/O، تنظیم گزینهٔ maxseq روی بیشینهٔ تعداد گزارش‌هایی است که می‌خواهید ذخیره کنید. به‌محض اینکه شمارهٔ توالی گزارش I/O به maxseq, برسد، به صفر بازنشانی می‌شود و sudoers هر گزارش I/O موجود را کوتاه و دوباره استفاده خواهد کرد.

محدودیت‌های عملگر !

به طور کلی “کاستن” دستورها از ALL با استفاده از عملگر ‘!’ کارآمد نیست. کاربر می‌تواند به سادگی با رونوشت گرفتن از دستور مورد نظر با نامی دیگر و اجرای آن، این محدودیت را دور بزند. برای نمونه:

bill	ALL = ALL, !SU, !SHELLS

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

به طور کلی، اگر کاربری دسترسی sudo ALL داشته باشد، صرف‌نظر از هرگونه عنصر ‘!’ در مشخصات کاربر، هیچ چیزی نمی‌تواند مانع از آن شود که برنامه‌ای بسازد که یک پوستهٔ root در اختیارش بگذارد (یا رونوشت اختصاصی خود را از یک پوسته ایجاد کند).

پیامدهای امنیتی fast_glob

اگر گزینهٔ fast_glob در حال استفاده باشد، نفی مطمئن دستورهایی که نام مسیر آن‌ها شامل نویسه‌های تطبیق الگو (همان نویسه‌های عام) است امکان‌پذیر نیست. دلیل این امر ناتوانی تابع fnmatch(3) در کتابخانهٔ C در تحلیل مسیرهای نسبی است. اگرچه این موضوع معمولاً برای قواعدی که مجوزها را اعطا می‌کنند تنها یک محدودیت ساده است، اما می‌تواند برای قواعدی که مجوزها را سلب یا لغو می‌کنند منجر به یک رخنهٔ امنیتی شود.

برای نمونه، ورودی زیر را در پروندهٔ sudoers در نظر بگیرید:

john	ALL = /usr/bin/passwd [a-zA-Z0-9]*, /usr/bin/chsh [a-zA-Z0-9]*,\
              /usr/bin/chfn [a-zA-Z0-9]*, !/usr/bin/* root

کاربر john در صورت فعال بودن fast_glob همچنان می‌تواند با رفتن به پوشهٔ /usr/bin و اجرای ‘./passwd root’ به جای آن، دستور ‘/usr/bin/passwd root’ را اجرا کند.

موضوع احتمالی دیگر این است که هنگام اجرای دستور توسط sudo باید به جای مسیر درج‌شده در پروندهٔ sudoers از دستور یا مسیر تعیین‌شده توسط کاربر استفاده شود. این مسئله می‌تواند منجر به شرایط رقابتی «زمان بررسی تا زمان استفاده» (TOCTOU) گردد.

نویسه‌های عام در آرگومان‌های دستور

آرگومان‌های خط فرمان به صورت یک رشتهٔ واحد و پیوسته تطبیق داده می‌شوند. این بدان معناست که یک نویسهٔ عام مانند ‘?’ یا ‘*’ فراتر از مرزهای کلمات نیز تطبیق می‌یابد، که ممکن است غیرمنتظره باشد. برای نمونه، در حالی که ورودی sudoers مانند:

%operator ALL = /bin/cat /var/log/messages*

اجرای دستوری مانند:

$ sudo cat /var/log/messages.1

را مجاز می‌شمارد، این مورد را نیز مجاز خواهد دانست:

$ sudo cat /var/log/messages /etc/shadow

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

%operator ALL = /bin/cat ^/var/log/messages[^[:space:]]*$

این عبارت منظم تنها با یک فایل تطبیق می‌یابد که نام آن با /var/log/messages آغاز شده و فاقد هرگونه نویسه فاصله در نام خود باشد. برای هر کار غیرجزئی، اغلب بهتر است پردازش خط فرمان خارج از فایل sudoers و در یک زبان اسکریپت‌نویسی انجام شود.

عبارت‌های منظم در نام دستورها

استفاده از یک عبارت منظم برای تطبیق نام دستور، همان پیامدهای امنیتیِ استفاده از گزینه fast_glob را دارد:

• هنگامی که نام مسیر یک عبارت منظم باشد، نفی مطمئن دستورها امکان‌پذیر نیست.
• هنگامی که sudo دستور را اجرا می‌کند، باید از دستور یا مسیر مشخص‌شده توسط کاربر به جای مسیر درج‌شده در فایل sudoers استفاده کند. این امر ممکن است منجر به شرایط رقابتیِ «زمان بررسی در برابر زمان استفاده» (time of check versus time of use) شود.

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

جلوگیری از گریز به پوسته (Shell escapes)

به محض اینکه sudo برنامه‌ای را اجرا کند، آن برنامه در انجام هر کاری آزاد است، از جمله اجرای برنامه‌های دیگر. این موضوع می‌تواند یک مسئله امنیتی باشد، زیرا غیرمعمول نیست که برنامه‌ای اجازه گریز به پوسته را بدهد؛ امری که به کاربر امکان می‌دهد کنترل دسترسی و ثبت وقایعِ sudo را دور بزند. برنامه‌های رایجی که امکان گریز به پوسته را فراهم می‌کنند شامل پوسته‌ها (طبیعتاً)، ویرایشگرها، صفحه‌بندها، برنامه‌های ایمیل و برنامه‌های ترمینال هستند.

چهار رویکرد اساسی برای این مسئله وجود دارد:

restrict

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

intercept

در بیشتر سیستم‌ها، قابلیت intercept در sudo می‌تواند برای رهگیری شفاف تلاش جهت اجرای یک دستور جدید، مجاز یا مسدود کردن آن بر اساس قوانین sudoers و ثبت نتیجه استفاده شود. برای نمونه، این قابلیت می‌تواند برای محدود کردن دستورات اجرا شده از درون یک پوسته یا ویرایشگر با دسترسی ممتاز استفاده شود.

دو سازوکار بنیادین وجود دارد که ممکن است برای پیاده‌سازی حالت intercept به کار روند: dso و trace. از تنظیم intercept_type می‌توان برای انتخاب میان آن‌ها استفاده کرد.

نخستین سازوکار، dso, توابع استاندارد کتابخانه C را که برای اجرای یک دستور استفاده می‌شوند بازنویسی می‌کند. این کار با تنظیم یک متغیر محیطی (معمولاً LD_PRELOAD) به مسیر یک شیء اشتراکی پویا، یا کتابخانه اشتراکی، حاوی نسخه‌های سفارشی از توابع کتابخانه‌ای execve(2), execl(3), execle(3), execlp(3), execv(3), execvp(3), execvpe(3), و system(3) انجام می‌شود که برای تصمیم‌گیری درباره خط‌مشی به sudo متصل می‌شوند. توجه داشته باشید که این سازوکار تنها برای برنامه‌های اجرایی با پیوند پویا اعمال می‌شود. رهگیری دستورها برای برنامه‌های با پیوند ایستا یا برنامه‌هایی که تحت شبیه‌سازی باینری اجرا می‌شوند از این طریق ممکن نیست. از آنجا که بیشتر بارگذارنده‌های پویا هنگام اجرای برنامه‌های set-user-ID و set-group-ID متغیر LD_PRELOAD (یا معادل آن) را نادیده می‌گیرند، sudoers به‌طور پیش‌فرض اجازه اجرای چنین برنامه‌هایی را در حالت intercept نمی‌دهد. سازوکار dso با پشتیبانی از SELinux RBAC در sudo's ناسازگار است (اما بخش زیر را ببینید). ‏SELinux به‌طور پیش‌فرض LD_PRELOAD را غیرفعال کرده و در وراثت توصیف‌گر فایل، که sudo به آن متکی است، تداخل ایجاد می‌کند.

سازوکار دوم، trace, روی سیستم‌های لینوکسی که از فیلتر کردن seccomp(2) پشتیبانی می‌کنند در دسترس است. این سازوکار از ptrace(2) و seccomp(2) برای رهگیری فراخوان سیستمی execve(2) به‌جای پیش‌بارگذاری یک شیء اشتراکی پویا استفاده می‌کند. هر دو نوع برنامه‌های اجرایی ایستا و پویا پشتیبانی می‌شوند و با حالت SELinux RBAC در sudo's سازگار است. توابعی که از فراخوان سیستمی execveat(2) استفاده می‌کنند، مانند fexecve(3), در حال حاضر رهگیری نمی‌شوند.

قابلیت intercept روی Solaris، *BSD، Linux، macOS، HP-UX 11.x و AIX 5.3 و بالاتر کار می‌کند. این قابلیت باید روی بیشتر سیستم‌عامل‌هایی که از متغیر محیطی LD_PRELOAD یا معادل آن پشتیبانی می‌کنند، پشتیبانی شود. رهگیری دستورهای درونی پوسته یا محدود کردن توانایی خواندن یا نوشتن فایل‌های حساس از داخل پوسته امکان‌پذیر نیست.

برای فعال‌سازی حالت رهگیری به‌ازای هر دستور، از برچسب INTERCEPT همان‌طور که در بخش User Specification در بالا مستند شده است استفاده کنید. این مثال دوباره در اینجا آورده شده است:

chuck	research = INTERCEPT: ALL

این به کاربر chuck اجازه می‌دهد تا هر دستوری را روی ماشین “research” در حالت رهگیری اجرا کند. هر دستوری که از طریق گریزهای پوسته اجرا شود، توسط sudo. اعتبارسنجی و ثبت خواهد شد. اگر مطمئن نیستید که سیستم شما توانایی پشتیبانی از intercept, را دارد یا خیر، می‌توانید آن را آزمایش کنید و بررسی کنید که آیا دستورهای خارجی اجراشده از طریق پوسته هنگام فعال بودن intercept ثبت می‌شوند یا خیر.

یک شرایط رقابت ذاتی بین زمانی که یک دستور در برابر قوانین sudoers بررسی می‌شود و زمانی که واقعاً به اجرا درمی‌آید، وجود دارد. اگر کاربری مجاز به اجرای دستورهای دلخواه باشد، ممکن است بتواند آرگومان‌های execve(2) را در برنامه، پس از تکمیل بررسی سیاست sudoers اما پیش از اجرای دستور جدید تغییر دهد. از نگارش 1.9.12 به بعد، روش trace بررسی خواهد کرد که دستور و آرگومان‌های آن پس از تکمیل execve(2) اما پیش از آنکه برنامهٔ جدید فرصت اجرا پیدا کند، تغییر نکرده باشند. این قابلیت در روش dso وجود ندارد. برای اطلاعات بیشتر، توضیحات تنظیم intercept_verify را ببینید.

log

دو روش مجزا اما مرتبط برای ثبت وقایع دستورهای اضافی وجود دارد. روش نخست، فعال‌سازی ثبت ورودی/خروجی با استفاده از پرچم log_output است. این کار خروجی دستور را ثبت می‌کند اما هنگام اجرای دستور اضافی، مدخلی در گزارش وقایع ایجاد نخواهد کرد. روش دوم، فعال‌سازی پرچم log_subcmds در sudoers است که با هر بار اجرای دستوری جدید، یک مدخل در گزارش وقایع ایجاد می‌کند. اگر ثبت ورودی/خروجی نیز فعال باشد، مدخل گزارش شامل یک آفست زمانی در گزارش ورودی/خروجی خواهد بود تا زمان دقیق اجرای دستور را مشخص کند. این آفست را می‌توان به ابزار sudoreplay(8) داد تا گزارش ورودی/خروجی را در همان لحظهٔ دقیق اجرای دستور بازپخش کند. پرچم log_subcmds از همان سازوکار intercept (به بالا رجوع کنید) استفاده می‌کند و دارای همان محدودیت‌ها است.

noexec

قابلیت noexec در sudo می‌تواند برای جلوگیری از اجرای هرگونه برنامهٔ دیگر توسط برنامه‌ای که با sudo اجرا شده، استفاده شود. در بیشتر سیستم‌ها، از همان سازوکار LD_PRELOAD مشابه intercept (به بالا رجوع کنید) استفاده می‌کند و از این رو همان هشدارها صادق هستند. قابلیت noexec می‌تواند اجرای دستورهایی که از طریق توابع execve(2), execl(3), execle(3), execlp(3), exect(3), execv(3), execveat(3), execvP(3), execvp(3), execvpe(3), fexecve(3), popen(3), posix_spawn(3), posix_spawnp(3), system(3), و wordexp(3) اجرا می‌شوند را مسدود کند. در لینوکس، یک فیلتر seccomp(2) برای پیاده‌سازی noexec. استفاده می‌شود. در Solaris 10 و بالاتر، noexec به جای متغیر محیطی LD_PRELOAD از امتیازات Solaris استفاده می‌کند.

برای فعال‌سازی noexec برای یک دستور، از برچسب NOEXEC همان‌گونه که در بخش مشخصات کاربر در بالا مستند شده است، استفاده کنید. در اینجا مجدداً همان نمونه آورده شده است:

aaron	shanty = NOEXEC: /usr/bin/more, /usr/bin/vi

این به کاربر aaron اجازه می‌دهد تا /usr/bin/more و /usr/bin/vi را با فعال بودن noexec اجرا کند. این کار مانع از اجرای دستورات دیگر (مانند یک پوسته) توسط آن دو دستور می‌شود. اگر مطمئن نیستید که سیستم شما از noexec پشتیبانی می‌کند یا خیر، می‌توانید آن را امتحان کرده و بررسی کنید که آیا در صورت فعال بودن noexec گریز به پوسته کار می‌کند یا خیر.

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

ویرایش امن

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

برخلاف سایر دستورات sudo ، ویرایشگر با مجوزهای کاربر اجراکننده و بدون تغییر در متغیرهای محیطی اجرا می‌شود. اطلاعات بیشتر در توضیحات مربوط به گزینه -e در sudo(8) موجود است.

به عنوان مثال، برای اجازه دادن به کاربر operator جهت ویرایش فایل “پیام روز” روی هر ماشینی:

operator ALL = sudoedit /etc/motd

سپس کاربر operator دستور sudoedit را به این صورت اجرا می‌کند:

$ sudoedit /etc/motd

ویرایشگر با دسترسی کاربر operator، نه root ، روی یک نسخه موقت از /etc/motd اجرا خواهد شد. پس از ویرایش فایل، /etc/motd با محتویات نسخه موقت به‌روزرسانی می‌شود.

به کاربران هرگز نباید دسترسی sudoedit برای ویرایش پرونده‌ای که در شاخه‌ای دارای دسترسی نوشتن برای کاربر قرار دارد (چه مستقیم یا با نویسه عام) داده شود. اگر کاربر به شاخه دسترسی نوشتن داشته باشد، امکان جایگزینی پرونده معتبر با پیوندی به پرونده دیگر وجود دارد که امکان ویرایش پرونده‌های دلخواه را فراهم می‌کند. برای جلوگیری از این امر، از نسخه 1.8.16 به بعد، پیوندهای نمادین در شاخه‌های قابل‌نوشتن دنبال نخواهند شد و sudoedit از ویرایش پرونده موجود در شاخه قابل‌نوشتن خودداری خواهد کرد مگر اینکه گزینه sudoedit_checkdir غیرفعال شده باشد یا کاربر فراخواننده root. باشد. علاوه بر این، در نسخه 1.8.15 و بالاتر، sudoedit از باز کردن پیوند نمادین خودداری خواهد کرد مگر اینکه گزینه sudoedit_follow فعال شده باشد یا دستور sudoedit با برچسب FOLLOW در پرونده sudoers پیشوند شده باشد.

بررسی‌های پرونده برچسب زمانی

sudoers مالکیت شاخه برچسب زمانی خود (/run/sudo/ts به‌طور پیش‌فرض) را بررسی می‌کند و اگر مالک آن root نباشد یا توسط کاربری غیر از root. قابل نوشتن باشد، محتویات شاخه را نادیده می‌گیرد. نسخه‌های قدیمی‌تر sudo پرونده‌های برچسب زمانی را در /tmp; ذخیره می‌کردند؛ این کار دیگر توصیه نمی‌شود زیرا در سیستم‌هایی که به کاربران غیرممتاز اجازه تغییر مالکیت پرونده‌های ایجادشده را می‌دهند، ممکن است کاربر خودش برچسب زمانی را ایجاد کند.

اگرچه شاخه برچسب زمانی باید در زمان راه‌اندازی مجدد سیستم پاک شود، اما همه سیستم‌ها شامل شاخه /run یا /var/run نیستند. برای جلوگیری از مشکلات احتمالی، sudoers در سیستم‌هایی که زمان راه‌اندازی سیستم در دسترس است، پرونده‌های برچسب زمانی مربوط به قبل از بوت شدن دستگاه را نادیده می‌گیرد.

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

sudoers برچسب‌های زمانی تنظیم‌شده برای آینده دور را نمی‌پذیرد. برچسب‌های زمانی با تاریخی بیشتر از current_time + 2 * TIMEOUT نادیده گرفته خواهند شد و sudoers گزارش و شکایت ثبت خواهد کرد.

اگر گزینه timestamp_type روی “tty”, تنظیم شده باشد، رکورد برچسب زمانی شامل شماره دستگاه پایانه‌ای است که کاربر با آن احراز هویت کرده است. این کار تفکیک به ازای هر پایانه را فراهم می‌کند، اما ممکن است رکوردهای برچسب زمانی همچنان پس از پایان نشست کاربر پابرجا بمانند.

مگر اینکه گزینهٔ timestamp_type روی “global”, تنظیم شده باشد، رکورد مهر زمانی شامل شناسهٔ نشست فرایندی که آخرین بار احراز هویت کرده نیز می‌شود. این کار از استفادهٔ فرایندها در نشست‌های پایانهٔ مختلف از یک رکورد مهر زمانی یکسان جلوگیری می‌کند. در سیستم‌هایی که زمان شروع فرایند قابل پرس‌وجو باشد، زمان شروع رهبر نشست در رکورد مهر زمانی ثبت می‌شود. اگر هیچ پایانه‌ای وجود نداشته باشد یا گزینهٔ timestamp_type روی “ppid”, تنظیم شده باشد، در عوض از زمان شروع فرایند والد استفاده می‌شود. در بیشتر موارد، این کار مانع از استفادهٔ مجدد از رکورد مهر زمانی بدون وارد کردن گذرواژه هنگام خروج و ورود دوبارهٔ کاربر می‌شود.