sudo و root در لینوکس؛ دسترسی ممتاز بدون بینظمی
تفاوت root و sudo، فایل sudoers با visudo، NOPASSWD، su، و اشتباههای خطرناک دسترسی ممتاز — با man sudo و sudoers.
بنیانگذار و مهندس محصول
کاربر root در لینوکس هویت با uid ۰ است و عملاً میتواند بیشتر قیدهای مجوز کلاسیک را دور بزند. کار کردن همیشگی بهعنوان root سریع به نظر میرسد و در عمل ردپای فردی را پاک میکند، اشتباه مخرب را آسان میکند، و با سرویسهای در حال اجرا تداخل هویتی میسازد. sudo راهی است تا کاربر عادی برای فرمانهای مشخص، موقتاً امتیاز بگیرد و سیستم ثبت کند چه کسی چه کرد.
صفحات راهنمای sudo(8) و sudoers(5) مرجع رسمی رفتار و سیاستاند. این مقاله مدل ذهنی root در برابر sudo، ویرایش امن با visudo، تلهٔ NOPASSWD، تفاوت با su، و الگوهای مناسب سرور و CI را پوشش میدهد. سختسازی SSH در ۱۵۹ مکمل ورود از راه دور است.
هدف حذف کامل دسترسی ممتاز نیست؛ هدف کنترل، حداقلسازی، و قابلیت حسابرسی است.
پاسخ کوتاه
روزمره با کاربر عادی کار کنید؛ برای کارهای مدیریتی از sudo استفاده کنید. سیاست را در sudoers با visudo بنویسید، نه با ویرایشگر خام روی فایلی که نحو خرابش شما را قفل میکند. ورود مستقیم root با رمز از راه دور را روی سرورهای اینترنتی ببندید و به کلید SSH + sudo تکیه کنید. NOPASSWD را فقط برای فرمانهای محدود اتوماسیون در نظر بگیرید، نه برای همه چیز.
sudo امتیاز قرض میدهد؛ root هویت را عوض میکند. قرض با سررسید و رسید بهتر از زندگی دائمی با کلید گاوصندوق است.
root چیست و چرا خطرناک است؟
root صاحب بسیاری از فایلهای سیستم است و میتواند کاربر بسازد، دستگاه خام بنویسد، و سرویس را بهعنوان هر کسی اجرا کند. یک rm اشتباه با root، یا یک اسکریپت اینترنتی، کافی است. علاوه بر این، وقتی همه root باشند، لاگ «چه کسی» ضعیف میشود. سرویسهای شبکه را عمداً غیرroot اجرا میکنند تا نفوذ به اپ برابر با نفوذ کامل به میزبان نباشد.
در کانتینر، root داخل namespace ممکن است با قابلیتهای محدود همراه باشد؛ باز هم الگوی «اپ با root» را بدون نیاز نیاورید.
sudo چگونه کار میکند؟
کاربر فرمان را با پیشوند sudo میزند؛ سرویس sudo سیاست sudoers را میخواند، در صورت نیاز رمز کاربر را میپرسد، و فرمان را با امتیاز هدف (معمولاً root) اجرا میکند. تیکت زمانی کوتاه باعث میشود برای چند فرمان پشتسرهم مدام رمز نپرسد — این راحتی است نه مجوز ابدی.
bash
whoami sudo whoami sudo -u postgres psql -c 'SELECT 1' sudo -l
sudo -l سیاست مؤثر شما را نشان میدهد. sudo -u برای اجرای فرمان بهعنوان کاربر دیگر بدون root کامل مفید است — مثلاً تست دسترسی سرویس.
sudoers و visudo
فایل اصلی معمولاً /etc/sudoers و قطعات /etc/sudoers.d/ است. فقط با visudo ویرایش کنید تا نحو سنجیده شود. یک خط اشتباه میتواند دسترسی ادمین را قطع کند یا بیش از حد باز کند.
bash
# نمونهٔ مفهومی — قبل از کپی، man sudoers را بخوانید # %sudo ALL=(ALL:ALL) ALL # deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload nginx
گروه sudo یا wheel در توزیعهای مختلف نام رایج برای ادمینهاست. کاربر را به آن گروه اضافه کردن الگوی اوبونتو است؛ باز هم سیاست ریزتر برای میزبانهای حساس بهتر است.
su در برابر sudo
su معمولاً به کاربر دیگر (اغلب root) سوییچ میکند و رمز همان کاربر هدف را میخواهد مگر root باشید. sudo رمز کاربر فعلی را میپرسد و سیاست مرکزی دارد. برای کار تیمی و حسابرسی، sudo ترجیح داده میشود. su - برای گرفتن محیط login کاربر هدف است؛ در اسکریپتها با احتیاط.
NOPASSWD و اتوماسیون
NOPASSWD برای فرمانهای مشخص در CI مفید است تا رمز در pipeline نماند. خطر: اگر فرمان کلی باشد یا کاربر CI نفوذ شود، مهاجم همان امتیاز را بدون رمز میگیرد. مسیر باینری را قفل کنید، استدلال را محدود کنید، و از wildcardهای خطرناک بپرهیزید. هرگز برای همهٔ فرمانها روی حساب انسان روزمره NOPASSWD نگذارید مگر بدانید چرا.
جدول عادت خوب / بد
| عادت | بهتر | بد |
|---|---|---|
| ورود SSH | کاربر عادی + کلید | root با رمز |
| نصب بسته | sudo apt ... | نشست root دائمی |
| تست سرویس | sudo -u svc ... | همه چیز بهعنوان root |
| ویرایش sudoers | visudo | nano مستقیم بدون backup |
| CI | sudoers محدود | کلید root در runner |
اشتباههای رایج
- echo رمز | sudo -S در اسکریپت و لاگ.
- chmod روی sudoers و شکستن امنیت یا دسترسی.
- دادن ALL به همهٔ توسعهدهندهها روی Production.
- فراموش کردن ثبت و چرخش اعضای گروه sudo.
- اجرای GUI یا مرورگر با sudo.
سوالات متداول
آیا باید حساب root را حذف کنم؟
معمولاً خیر؛ ورود مستقیم را محدود کنید. حساب uid ۰ لازم است ولی در دسترس شبکه نباشد.
رمز sudo همان رمز ورود است؟
بهطور پیشفرض بله، رمز کاربر فراخوان. میتوان سیاستهای دیگر تعریف کرد؛ مستند توزیع را بخوانید.
چرا sudo میگوید not in sudoers؟
کاربر در سیاست نیست. از حساب ادمین دیگر یا کنسول ابری کاربر را به گروه درست اضافه کنید.
آیا sudo جایگزین کامل MAC و فایروال است؟
خیر. لایهٔ هویت ممتاز است؛ بقیه کنترلها سر جایشان میمانند.
doas یا pkexec چطور؟
جایگزین یا مکمل در بعضی محیطها هستند. روی سرورهای کلاسیک لینوکس، sudo استاندارد رایج است.
مسیر پیشنهادی روی VPS تازه
- کاربر عادی با کلید SSH بسازید.
- او را به گروه sudo اضافه کنید و ورود را تست کنید.
- PermitRootLogin را طبق سیاست سختسازی محدود کنید.
- sudo -l را بررسی کنید.
- برای deploy، کاربر/سیاست جدا با حداقل فرمانها در نظر بگیرید.
سناریو و نکتهٔ تکمیلی (1)
هر بار که sudo موفق میشود، سیستم باید بداند چه کسی، چه فرمانی، روی چه میزبانی اجرا کرد. همین ردپا در تحقیق حادثه ارزش طلا دارد. اگر همه با root خالص وارد میشوند، آن ردپا از بین میرود و فرهنگ «کسی بوده» جایگزین مسئولیت میشود.
حداقل دسترسی در sudoers یعنی فرمانهای مشخص، استدلالهای محدود، و پرهیز از ALL=(ALL) NOPASSWD:ALL روی حسابهای روزمره. استثنای اضطراری را جدا و زماندار کنید. ویرایش sudoers را فقط با visudo انجام دهید تا نحو خراب، قفلتان نکند.
برای اتوماسیون، کاربر CI با کلید جدا و sudoers محدود به وظایف deploy بهتر از قرض گرفتن حساب انسان است. چرخش کلید و جداسازی محیط staging/production را در همان سیاست ببینید.
آموزش تیم دربارهٔ تفاوت su و sudo جلوی عادتهای قدیمی را میگیرد. su به root بدون نیاز، سطح حمله را بالا میبرد؛ sudo با تیکت کوتاهمدت تعادل بهتری بین سرعت و کنترل میسازد.
سناریو و نکتهٔ تکمیلی (2)
هر بار که sudo موفق میشود، سیستم باید بداند چه کسی، چه فرمانی، روی چه میزبانی اجرا کرد. همین ردپا در تحقیق حادثه ارزش طلا دارد. اگر همه با root خالص وارد میشوند، آن ردپا از بین میرود و فرهنگ «کسی بوده» جایگزین مسئولیت میشود.
حداقل دسترسی در sudoers یعنی فرمانهای مشخص، استدلالهای محدود، و پرهیز از ALL=(ALL) NOPASSWD:ALL روی حسابهای روزمره. استثنای اضطراری را جدا و زماندار کنید. ویرایش sudoers را فقط با visudo انجام دهید تا نحو خراب، قفلتان نکند.
برای اتوماسیون، کاربر CI با کلید جدا و sudoers محدود به وظایف deploy بهتر از قرض گرفتن حساب انسان است. چرخش کلید و جداسازی محیط staging/production را در همان سیاست ببینید.
آموزش تیم دربارهٔ تفاوت su و sudo جلوی عادتهای قدیمی را میگیرد. su به root بدون نیاز، سطح حمله را بالا میبرد؛ sudo با تیکت کوتاهمدت تعادل بهتری بین سرعت و کنترل میسازد.
سناریو و نکتهٔ تکمیلی (3)
هر بار که sudo موفق میشود، سیستم باید بداند چه کسی، چه فرمانی، روی چه میزبانی اجرا کرد. همین ردپا در تحقیق حادثه ارزش طلا دارد. اگر همه با root خالص وارد میشوند، آن ردپا از بین میرود و فرهنگ «کسی بوده» جایگزین مسئولیت میشود.
حداقل دسترسی در sudoers یعنی فرمانهای مشخص، استدلالهای محدود، و پرهیز از ALL=(ALL) NOPASSWD:ALL روی حسابهای روزمره. استثنای اضطراری را جدا و زماندار کنید. ویرایش sudoers را فقط با visudo انجام دهید تا نحو خراب، قفلتان نکند.
برای اتوماسیون، کاربر CI با کلید جدا و sudoers محدود به وظایف deploy بهتر از قرض گرفتن حساب انسان است. چرخش کلید و جداسازی محیط staging/production را در همان سیاست ببینید.
آموزش تیم دربارهٔ تفاوت su و sudo جلوی عادتهای قدیمی را میگیرد. su به root بدون نیاز، سطح حمله را بالا میبرد؛ sudo با تیکت کوتاهمدت تعادل بهتری بین سرعت و کنترل میسازد.
سناریو و نکتهٔ تکمیلی (4)
هر بار که sudo موفق میشود، سیستم باید بداند چه کسی، چه فرمانی، روی چه میزبانی اجرا کرد. همین ردپا در تحقیق حادثه ارزش طلا دارد. اگر همه با root خالص وارد میشوند، آن ردپا از بین میرود و فرهنگ «کسی بوده» جایگزین مسئولیت میشود.
حداقل دسترسی در sudoers یعنی فرمانهای مشخص، استدلالهای محدود، و پرهیز از ALL=(ALL) NOPASSWD:ALL روی حسابهای روزمره. استثنای اضطراری را جدا و زماندار کنید. ویرایش sudoers را فقط با visudo انجام دهید تا نحو خراب، قفلتان نکند.
برای اتوماسیون، کاربر CI با کلید جدا و sudoers محدود به وظایف deploy بهتر از قرض گرفتن حساب انسان است. چرخش کلید و جداسازی محیط staging/production را در همان سیاست ببینید.
آموزش تیم دربارهٔ تفاوت su و sudo جلوی عادتهای قدیمی را میگیرد. su به root بدون نیاز، سطح حمله را بالا میبرد؛ sudo با تیکت کوتاهمدت تعادل بهتری بین سرعت و کنترل میسازد.
سناریو و نکتهٔ تکمیلی (5)
هر بار که sudo موفق میشود، سیستم باید بداند چه کسی، چه فرمانی، روی چه میزبانی اجرا کرد. همین ردپا در تحقیق حادثه ارزش طلا دارد. اگر همه با root خالص وارد میشوند، آن ردپا از بین میرود و فرهنگ «کسی بوده» جایگزین مسئولیت میشود.
حداقل دسترسی در sudoers یعنی فرمانهای مشخص، استدلالهای محدود، و پرهیز از ALL=(ALL) NOPASSWD:ALL روی حسابهای روزمره. استثنای اضطراری را جدا و زماندار کنید. ویرایش sudoers را فقط با visudo انجام دهید تا نحو خراب، قفلتان نکند.
برای اتوماسیون، کاربر CI با کلید جدا و sudoers محدود به وظایف deploy بهتر از قرض گرفتن حساب انسان است. چرخش کلید و جداسازی محیط staging/production را در همان سیاست ببینید.
آموزش تیم دربارهٔ تفاوت su و sudo جلوی عادتهای قدیمی را میگیرد. su به root بدون نیاز، سطح حمله را بالا میبرد؛ sudo با تیکت کوتاهمدت تعادل بهتری بین سرعت و کنترل میسازد.
خلاصه
root قدرت کامل است؛ sudo قدرت قرضی با سیاست و لاگ. با کاربر عادی زندگی کنید، visudo را جدی بگیرید، NOPASSWD را محدود کنید، و ورود root از راه دور را سخت کنید. قدم بعد: فرایندها را بشناسید تا بدانید سرویسها با چه هویتی زنده میمانند.
منابع و مراجع
- man7.org — sudo(8) — https://man7.org/linux/man-pages/man8/sudo.8.html
- man7.org — sudoers(5) — https://man7.org/linux/man-pages/man5/sudoers.5.html
- man7.org — su(1) — https://man7.org/linux/man-pages/man1/su.1.html
- Ubuntu Server documentation — https://documentation.ubuntu.com/server/
- sudo project documentation — https://www.sudo.ws/docs/
نویسنده
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.
