SUDO.CONF(5) فایلهای پیکربندی SUDO.CONF(5)

sudo.conf - پرونده پیکربندی افزونهها و تنظیمات دستور sudo

پرونده /etc/sudo.conf گزینههای عمومی بخش فرانتاند sudo، بارگذاری افزونههای امنیتی (plugins) و دیباگ را پیکربندی میکند.

پرونده sudo.conf از دستورالعمل‌های زیر پشتیبانی می‌کند که جزئیات آن‌ها در ادامه آمده است:

یک افزونه برای تایید (approval)، بازرسی (audit)، ثبت گزارش ورودی/خروجی (I/O logging)، یا خط‌مشی امنیتی (security policy).
یک مسیر ناوابسته به افزونه (plugin-agnostic).
یک تنظیم فرانت‌اند، مانند disable_coredump یا group_source.
فلگ‌های اشکال‌زدایی جهت کمک به دیباگ sudo، sudoreplay، visudo و افزونه sudoers.

علامت هش (#) برای نشان دادن کامنت استفاده می‌شود. نویسه کامنت و هر متنی پس از آن تا انتهای خط نادیده گرفته می‌شوند.

خطوط طولانی را می‌توان با قرار دادن یک بک‌اسلش (\) به عنوان آخرین نویسه در انتهای خط ادامه داد. فاصله‌های خالی ابتدای خط حتی در صورت استفاده از نویسه ادامه‌دهنده حذف می‌شوند.

خطوط غیر کامنت که با Plugin، Path، Debug یا Set شروع نشوند، در سکوت نادیده گرفته می‌شوند.

پرونده sudo.conf همیشه در لوکال C تجزیه می‌شود.

دستور sudo از یک معماری افزونه برای خط‌مشی‌های امنیتی و ثبت ورودی/خروجی پشتیبانی می‌کند. اشخاص ثالث می‌توانند افزونه‌های خط‌مشی و لاگ I/O خود را توسعه داده و توزیع کنند تا به‌صورت یکپارچه با فرانت‌اند sudo کار کنند. افزونه‌ها به‌طور پویا بر اساس محتویات sudo.conf بارگذاری می‌شوند.

یک خط Plugin از کلمه کلیدی Plugin تشکیل شده است که به دنبال آن symbol_name و path به شیء مشترک پویا (dynamic shared object) حاوی افزونه قرار می‌گیرد. مقدار symbol_name نام یکی از ساختارهای struct approval_plugin، struct audit_plugin، struct io_plugin یا struct policy_plugin است که توسط افزونه تعریف شده است. اگر افزونه‌ای چندین نوع افزونه را پیاده‌سازی کند، باید برای هر نام نماد یک خط Plugin جداگانه وجود داشته باشد. مسیر path می‌تواند مطلق یا نسبی باشد. اگر مطلق نباشد، نسبت به دایرکتوری مشخص‌شده توسط تنظیم plugin_dir در Path در نظر گرفته می‌شود که پیش‌فرض آن /usr/libexec/sudo است. به عبارت دیگر:

Plugin sudoers_policy sudoers.so

معادل است با:

Plugin sudoers_policy /usr/libexec/sudo/sudoers.so

اگر افزونه به جای نصب به عنوان یک شیء مشترک پویا، به‌صورت ایستا در باینری sudo کامپایل شده باشد، مسیر path باید بدون پیشوند دایرکتوری مشخص شود، زیرا در واقع در فایل‌سیستم وجود ندارد. برای مثال:

Plugin sudoers_policy sudoers.so

از نگارش 1.8.5 به بعد sudo، هر پارامتر اضافی پس از path به عنوان آرگومان به تابع open افزونه ارسال می‌شود. برای مثال، برای لغو حالت پیش‌فرض فایل sudoers تعیین‌شده در زمان کامپایل:

Plugin sudoers_policy sudoers.so sudoers_mode=0440

برای مشاهده فهرست آرگومان‌های پشتیبانی‌شده به صفحه راهنمای sudoers(5) مراجعه کنید.

یک شیء مشترک پویا می‌تواند شامل چندین افزونه باشد که هرکدام نام نماد متفاوتی دارند. مالک این پرونده باید شناسه کاربری 0 (root) باشد و فقط توسط مالک آن قابل نوشتن باشد. به دلیل ابهاماتی که ممکن است از خط‌مشی‌های مرکب ایجاد شود، تنها یک افزونه خط‌مشی (policy plugin) را می‌توان مشخص کرد. این محدودیت برای افزونه‌های ورودی/خروجی (I/O plugins) اعمال نمی‌شود.

اگر پرونده sudo.conf وجود نداشته باشد یا شامل هیچ خط Plugin نباشد، افزونه sudoers به‌عنوان خط‌مشی امنیتی پیش‌فرض، برای ثبت I/O (در صورت فعال بودن در خط‌مشی) و برای بازرسی استفاده خواهد شد. این معادل موارد زیر است:

Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
Plugin sudoers_audit sudoers.so

از نگارش 1.9.1 به بعد sudo، بخشی از قابلیت‌های لاگینگ افزونه sudoers از افزونه خط‌مشی به یک افزونه بازرسی (audit plugin) منتقل شده است. برای حفظ سازگاری با پرونده‌های sudo.conf نسخه‌های قدیمی‌تر sudo، اگر sudoers به عنوان خط‌مشی امنیتی پیکربندی شده باشد، به عنوان افزونه بازرسی نیز استفاده خواهد شد. این امر تضمین می‌کند که رفتار ثبت گزارش با نسخه‌های 1.9.0 و پایین‌تر sudo سازگار بماند.

برای اطلاعات بیشتر درباره معماری افزونه‌های sudo، به صفحه راهنمای sudo_plugin(5) مراجعه کنید.

یک خط Path شامل کلمه کلیدی Path است که پس از آن نام مسیر و مقدار آن قرار می‌گیرد. برای مثال:

Path intercept /usr/libexec/sudo/sudo_intercept.so
Path noexec /usr/libexec/sudo/sudo_noexec.so
Path askpass /usr/X11R6/bin/ssh-askpass

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

مسیرهای ناوابسته به افزونه زیر را می‌توان در پرونده /etc/sudo.conf تنظیم کرد:

مسیر کامل به یک برنامه کمکی برای خواندن رمز عبور کاربر در زمانی که هیچ ترمینالی در دسترس نیست. این مورد زمانی رخ می‌دهد که sudo از یک برنامه گرافیکی (برخلاف متنی) اجرا شود. برنامه مشخص‌شده توسط askpass باید آرگومان ارسال‌شده به خود را به عنوان اعلان (prompt) نمایش دهد و رمز عبور کاربر را در خروجی استاندارد بنویسد. مقدار askpass را می‌توان با متغیر محیطی SUDO_ASKPASS بازنویسی کرد.
یک مسیر جستجوی مرتب‌شده و جداشده با دونقطه از دایرکتوری‌ها جهت جستجوی گره‌های دستگاه. این تنظیم هنگام نگاشت شماره دستگاه tty فرایند به نام دستگاه در سیستم‌هایی که چنین سازوکاری را ارائه نمی‌دهند استفاده می‌شود. دستور Sudo در زیردایرکتوری‌ها جستجوی بازگشتی انجام نمی‌دهد /dev قرار داشته باشند، آن مسیر باید صراحتاً در devsearch ذکر شود. مقدار پیش‌فرض آن عبارت است از:
/dev/pts:/dev/vt:/dev/term:/dev/zcons:/dev/pty:/dev

این گزینه در سیستم‌هایی که از توابع devname یا _ttyname_dev پشتیبانی می‌کنند (مانند BSD، macOS و Solaris) نادیده گرفته می‌شود.

مسیر کامل به یک کتابخانه مشترک حاوی پوشش‌هایی (wrappers) برای توابع کتابخانه‌ای execve(2)، execl(3)، execle(3)، execlp(3)، execv(3)، execvp(3)، execvpe(3) و system(3) که تلاش‌ها برای اجرای دستورات بعدی را رهگیری کرده و پیش از اجازه اجرای آن‌ها یک بررسی خط‌مشی انجام می‌دهد. این برای پیاده‌سازی قابلیت intercept در سیستم‌هایی که از LD_PRELOAD یا معادل آن پشتیبانی می‌کنند به کار می‌رود. مقدار پیش‌فرض آن /usr/libexec/sudo/sudo_intercept.so است.
مسیر کامل به یک کتابخانه مشترک حاوی پوشش‌هایی برای توابع کتابخانه‌ای 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) که از اجرای دستورات بعدی جلوگیری می‌کنند. این برای پیاده‌سازی قابلیت noexec در سیستم‌هایی که از LD_PRELOAD یا معادل آن پشتیبانی می‌کنند به کار می‌رود. مقدار پیش‌فرض آن /usr/libexec/sudo/sudo_noexec.so است.
دایرکتوری پیش‌فرض برای جستجوی افزونه‌هایی که بدون مسیر کامل مشخص شده‌اند. مقدار پیش‌فرض آن /usr/libexec/sudo است.
مسیر کامل به باینری sesh. این تنظیم تنها زمانی استفاده می‌شود که sudo با پشتیبانی از SELinux ساخته شده باشد. مقدار پیش‌فرض آن /usr/libexec/sudo/sesh است.

پرونده sudo.conf همچنین از تنظیمات فرانت‌اند زیر پشتیبانی می‌کند:

تولید تخلیه حافظه هسته (Core dump) خود sudo به‌طور پیش‌فرض غیرفعال است تا از افشای اطلاعات حساس احتمالی جلوگیری شود. برای کمک به دیباگ کردن خطاهای کرش sudo، ممکن است بخواهید تولید core dump را با قرار دادن disable_coredump روی مقدار false در پرونده sudo.conf به صورت زیر فعال کنید:
Set disable_coredump false

تمام سیستم‌های‌عامل مدرن محدودیت‌هایی را بر تولید core dump از فرایندهای set-user-ID مانند sudo اعمال می‌کنند، بنابراین این گزینه را می‌توان بدون به خطر انداختن امنیت فعال کرد. برای دریافت واقعی یک فایل core از sudo، احتمالاً باید ایجاد core dump را برای فرایندهای set-user-ID فعال سازید. در سیستم‌های BSD و لینوکس این کار با دستور sysctl(8) انجام می‌شود. در سولاریس، دستور coreadm(1m) برای پیکربندی رفتار core dump استفاده می‌شود.

این تنظیم تنها در نگارش 1.8.4 و بالاتر sudo در دسترس است.

دستور sudo فهرست گروه‌های کاربری که دستور را اجرا کرده به افزونه‌های خط‌مشی و ورودی/خروجی ارسال می‌کند. در بیشتر سیستم‌ها، حد بالایی برای تعداد گروه‌هایی که یک کاربر می‌تواند هم‌زمان عضو آن‌ها باشد وجود دارد (معمولاً ۱۶ برای سازگاری با NFS). در سیستم‌های دارای ابزار getconf(1)، اجرای دستور:
getconf NGROUPS_MAX

حداکثر تعداد گروه‌ها را برمی‌گرداند.

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

تنظیم group_source به مدیر سیستم اجازه می‌دهد این رفتار پیش‌فرض را تغییر دهد. مقادیر پشتیبانی‌شده برای group_source عبارتند از:

استفاده از لیست ایستای گروه‌ها که هسته برمی‌گرداند. دریافت لیست گروه‌ها به این روش بسیار سریع است اما مشمول حد بالایی است که در بالا توضیح داده شد. این لیست از این جهت «ایستا» است که تغییرات اعمال‌شده در پایگاه داده گروه‌ها پس از ورود کاربر را منعکس نمی‌کند. این رفتار پیش‌فرض قبل از نگارش 1.8.7 بود.
پرس‌وجوی مستقیم و همیشگی از پایگاه داده گروه‌ها. این روش از این جهت «پویا» است که تغییرات اعمال‌شده در پایگاه داده گروه‌ها پس از ورود کاربر در لیست منعکس می‌شود. در برخی سیستم‌ها، پرس‌وجو از پایگاه داده گروه‌ها برای تمام گروه‌های یک کاربر در صورت شبکه‌ای بودن پایگاه داده ممکن است زمان‌بر باشد. اکثر سیستم‌های‌عامل روش بهینه‌ای برای این پرس‌وجوها ارائه می‌دهند. در حال حاضر sudo از پرس‌وجوهای بهینه در AIX، BSD، HP-UX، Linux، macOS و Solaris پشتیبانی می‌کند. این رفتار پیش‌فرض در macOS از نسخه 1.9.6 به بعد است.
تنها در صورتی از پایگاه داده گروه‌ها استعلام می‌شود که لیست ایستای ارائه‌شده توسط هسته دارای حداکثر تعداد ورودی‌ها باشد. این رفتار پیش‌فرض در سیستم‌هایی به غیر از macOS از نسخه 1.8.7 به بعد است.

برای مثال، برای آنکه sudo تنها از لیست ایستای هسته استفاده کند:

Set group_source static

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

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

این تنظیم تنها در نگارش 1.8.7 و بالاتر sudo موجود است. در نگارش‌های 1.8.24 و بالاتر نیازی به آن نیست و ممکن است در نسخه‌های آینده حذف شود.

به‌طور پیش‌فرض، sudo رابط‌های شبکه سیستم را بررسی کرده و آدرس IP هر رابط فعال را به افزونه خط‌مشی ارسال می‌کند. این امکان را فراهم می‌سازد که افزونه قوانین را بر اساس آدرس IP بدون نیاز به پرس‌وجو از DNS تطبیق دهد. در سیستم‌های لینوکس با تعداد زیادی رابط مجازی، این کار ممکن است زمان قابل توجهی ببرد. اگر تطبیق بر اساس IP مورد نیاز نباشد، می‌توان بررسی رابط‌های شبکه را به صورت زیر غیرفعال کرد:
Set probe_interfaces false

این تنظیم در نسخه 1.8.10 و بالاتر sudo در دسترس است.

نسخه‌های 1.8.4 و بالاتر sudo از یک چارچوب انعطاف‌پذیر اشکال‌زدایی پشتیبانی می‌کنند که می‌تواند در صورت بروز مشکل، فعالیت‌های داخلی sudo را ثبت کند.

یک خط Debug شامل کلمه کلیدی Debug است که پس از آن نام برنامه، افزونه یا شیء مشترک مورد نظر برای دیباگ، نام فایل لاگ دیباگ و فهرستی از فلگ‌های اشکال‌زدایی جداشده با کاما می‌آید. ساختار نگارشی فلگ‌های دیباگ استفاده‌شده توسط sudo، افزونه sudoers و برنامه‌ها و اشیاء مشترک مرتبط با آن به صورت subsystem@priority است، اما یک افزونه ثالث آزاد است تا زمانی که از کاما (,) استفاده نکند، قالب دیگری را به کار ببرد.

مثال‌ها:

Debug sudo /var/log/sudo_debug all@warn,plugin@info

تمام پیام‌های اشکال‌زدایی در سطح warn و بالاتر و همچنین پیام‌های در سطح info را برای زیرسیستم افزونه ثبت می‌کند.

Debug sudo_intercept.so /var/log/intercept_debug all@debug

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

از نگارش 1.8.12 به بعد sudo، می‌توان چندین مدخل Debug را برای هر برنامه مشخص کرد. نسخه‌های قدیمی‌تر تنها از یک ورودی Debug به ازای هر برنامه پشتیبانی می‌کردند. همچنین از نگارش 1.8.12 به بعد ورودی‌های دیباگ ویژه افزونه‌ها نیز پشتیبانی می‌شوند و بر اساس نام پایه افزونه بارگذاری‌شده (برای مثال sudoers.so) یا مسیر کامل افزونه تطبیق داده می‌شوند. پیش از این، افزونه sudoers همان ورودی Debug فرانت‌اند sudo را به اشتراک می‌گذاشت و نمی‌توانست به‌طور جداگانه پیکربندی شود.

اولویت‌های زیر به ترتیب کاهش شدت پشتیبانی می‌شوند: crit، err، warn، notice، diag، info، trace و debug. هر اولویت پس از مشخص شدن، تمام اولویت‌های بالاتر از خود را نیز شامل می‌شود. برای مثال، اولویت notice شامل پیام‌های دیباگ ثبت‌شده در سطح notice و بالاتر خواهد بود.

اولویت‌های trace و debug همچنین شامل ردگیری فراخوانی توابع (function call tracing) هستند که زمان ورود به یک تابع و زمان بازگشت از آن را ثبت می‌کند. به عنوان مثال، ردگیری زیر مربوط به تابع get_user_groups واقع در src/sudo.c است:

sudo[123] -> get_user_groups @ src/sudo.c:385
sudo[123] <- get_user_groups @ src/sudo.c:429 := groups=10,0,5

هنگام ورود به تابع که با یک پیکان به سمت راست (->) مشخص شده است، برنامه، شناسه فرایند (PID)، تابع، فایل منبع و شماره خط ثبت می‌شوند. هنگامی که تابع بازمی‌گردد که با یک پیکان به سمت چپ (<-) نشان داده شده است، همان اطلاعات به همراه مقدار بازگشتی ثبت می‌گردد. در این مورد، مقدار بازگشتی یک رشته است.

زیرسیستم‌های زیر توسط فرانت‌اند sudo استفاده می‌شوند:

با تمامی زیرسیستم‌ها مطابقت دارد
پردازش آرگومان‌های خط فرمان
گفتگوی تعاملی با کاربر
دستور sudoedit
زیرسیستم رویدادها
اجرای دستور
تابع اصلی sudo
مدیریت رابط‌های شبکه
ارتباط با افزونه
پیکربندی افزونه
کدهای مربوط به شبه‌ترمینال (pseudo-terminal)
مدیریت ویژه SELinux
توابع سودمند و کمکی
مدیریت utmp

افزونه sudoers(5) از زیرسیستم‌های بیشتری پشتیبانی می‌کند.

/etc/sudo.conf
پیکربندی فرانت‌اند sudo

#
# Default /etc/sudo.conf file
#
# Sudo plugins:
#   Plugin plugin_name plugin_path plugin_options ...
#
# The plugin_path is relative to /usr/libexec/sudo unless
#   fully qualified.
# The plugin_name corresponds to a global symbol in the plugin
#   that contains the plugin interface structure.
# The plugin_options are optional.
#
# The sudoers plugin is used by default if no Plugin lines are present.
#Plugin sudoers_policy sudoers.so
#Plugin sudoers_io sudoers.so
#Plugin sudoers_audit sudoers.so
#
# Sudo askpass:
#   Path askpass /path/to/askpass
#
# An askpass helper program may be specified to provide a graphical
# password prompt for "sudo -A" support.  Sudo does not ship with its
# own askpass program but can use the OpenSSH askpass.
#
# Use the OpenSSH askpass
#Path askpass /usr/X11R6/bin/ssh-askpass
#
# Use the Gnome OpenSSH askpass
#Path askpass /usr/libexec/openssh/gnome-ssh-askpass
#
# Sudo device search path:
#   Path devsearch /dev/path1:/dev/path2:/dev
#
# A colon-separated list of paths to check when searching for a user's
# terminal device.
#
#Path devsearch /dev/pts:/dev/vt:/dev/term:/dev/zcons:/dev/pty:/dev
#
# Sudo command interception:
#   Path intercept /path/to/sudo_intercept.so
#
# Path to a shared library containing replacements for the execv()
# and execve() library functions that perform a policy check to verify
# the command is allowed and simply return an error if not.  This is
# used to implement the "intercept" functionality on systems that
# support LD_PRELOAD or its equivalent.
#
# The compiled-in value is usually sufficient and should only be changed
# if you rename or move the sudo_intercept.so file.
#
#Path intercept /usr/libexec/sudo/sudo_intercept.so
#
# Sudo noexec:
#   Path noexec /path/to/sudo_noexec.so
#
# Path to a shared library containing replacements for the execv()
# family of library functions that just return an error.  This is
# used to implement the "noexec" functionality on systems that support
# LD_PRELOAD or its equivalent.
#
# The compiled-in value is usually sufficient and should only be changed
# if you rename or move the sudo_noexec.so file.
#
#Path noexec /usr/libexec/sudo/sudo_noexec.so
#
# Sudo plugin directory:
#   Path plugin_dir /path/to/plugins
#
# The default directory to use when searching for plugins that are
# specified without a fully qualified path name.
#
#Path plugin_dir /usr/libexec/sudo
#
# Core dumps:
#   Set disable_coredump true|false
#
# By default, sudo disables core dumps while it is executing (they
# are re-enabled for the command that is run).
# To aid in debugging sudo problems, you may wish to enable core
# dumps by setting "disable_coredump" to false.
#
#Set disable_coredump false
#
# User groups:
#   Set group_source static|dynamic|adaptive
#
# Sudo passes the user's group list to the policy plugin.
# If the user is a member of the maximum number of groups (usually 16),
# sudo will query the group database directly to be sure to include
# the full list of groups.
#
# On some systems, this can be expensive so the behavior is configurable.
# The "group_source" setting has three possible values:
#   static   - use the user's list of groups returned by the kernel.
#   dynamic  - query the group database to find the list of groups.
#   adaptive - if user is in less than the maximum number of groups.
#              use the kernel list, else query the group database.
#
#Set group_source static
#
# Sudo interface probing:
#   Set probe_interfaces true|false
#
# By default, sudo will probe the system's network interfaces and
# pass the IP address of each enabled interface to the policy plugin.
# On systems with a large number of virtual interfaces this may take
# a noticeable amount of time.
#
#Set probe_interfaces false
#
# Sudo debug files:
#   Debug program /path/to/debug_log subsystem@priority[,subsyste@priority]
#
# Sudo and related programs support logging debug information to a file.
# The program is typically sudo, sudoers.so, sudoreplay, or visudo.
#
# Subsystems vary based on the program; "all" matches all subsystems.
# Priority may be crit, err, warn, notice, diag, info, trace, or debug.
# Multiple subsystem@priority may be specified, separated by a comma.
#
#Debug sudo /var/log/sudo_debug all@warn,plugin@info
#Debug sudoers.so /var/log/sudoers_debug all@debug

sudo_plugin(5)، sudoers(5)، sudo(8)

افراد بسیاری در طول سال‌ها روی sudo کار کرده‌اند؛ این نگارش عمدتاً از کدهای نوشته‌شده توسط افراد زیر تشکیل شده است:

Todd C. Miller

برای مشاهده فهرست کامل افرادی که در پروژه sudo مشارکت داشته‌اند، پرونده CONTRIBUTORS.md را در توزیع sudo یا نشانی https://www.sudo.ws/about/contributors ببینید.

اگر فکر می‌کنید باگی در sudo یافته‌اید، می‌توانید گزارش اشکال را در https://bugzilla.sudo.ws ارسال کنید.

پشتیبانی رایگان محدود از طریق فهرست ایمیل sudo-users در دسترس است، برای عضویت یا جستجو در آرشیو نشانی https://www.sudo.ws/mailman/listinfo/sudo-users را ببینید.

برنامه sudo به صورت «همان‌گونه که هست» (AS IS) ارائه می‌شود و هرگونه ضمانت صریح یا ضمنی، شامل و نه محدود به، ضمانت‌های ضمنی تجارت و تناسب با یک هدف خاص رد می‌شود. برای جزئیات کامل پرونده LICENSE.md ارائه‌شده همراه با sudo یا نشانی https://www.sudo.ws/about/license را ملاحظه فرمایید.

مه ۲۰۲۵ sudo