Ubuntu 26.04-এ sudo-rs: sudoers-এ কী বদলাবে

Ubuntu-এ sudo-rs কী পরিবর্তন করে

Ubuntu 26.04 LTS-এ sudo-rs ডিফল্ট sudo হিসেবে সরবরাহ করা হয়। তাই নতুন সার্ভারে sudo কমান্ড চালালে মূল C প্রোগ্রামের বদলে Rust-এ পুনর্লিখিত সংস্করণটি চলে। অধিকাংশ sudoers ফাইল আগের মতোই কাজ করে। যে নিয়মটি সমস্যায় পড়ে, সেটিতে command-এর arguments-এর মধ্যে wildcard থাকে। কারণ sudo-rs argument text-এর ওপর glob pattern মিলিয়ে দেখে না।

Ubuntu 25.10-এ প্রথম এই পরিবর্তন করা হয় এবং 26.04 LTS-এও তা রাখা হয়েছে। Ubuntu 24.04 LTS প্রভাবিত নয়, কারণ আপনি হাতে sudo-rs install না করলে সেখানে এখনও মূল sudo নির্বাচন করা হয়। এই পরিবর্তনটি গুরুত্বপূর্ণ হয়ে ওঠে যখন আপনি Ubuntu 24.04 থেকে 26.04-এ upgrade করেন, অথবা নতুন release-এ নতুন server তৈরি করেন। আপনি যদি interim release-ও চালান, server-এ LTS এবং interim Ubuntu release-এর পার্থক্য ব্যাখ্যা করে কোন machine-এ এই ধরনের পরিবর্তন আগে কার্যকর হয়।

আপনার সার্ভারে আসলে কোন sudo চলছে তা পরীক্ষা করুন

Release number দেখে এটি নির্ধারণ করবেন না। মেশিনকেই জিজ্ঞেস করুন।

sudo --version
update-alternatives --config sudo
dpkg -l 'sudo*'

Internet-এর যেকোনো version table-এর তুলনায়, এই পৃষ্ঠাটিসহ, আপনার নিজের মেশিনে sudo --version-কে বেশি বিশ্বাস করুন। update-alternatives --config sudo হলো উত্তরের অন্য অংশ: এটি /usr/bin/sudo-এর ইনস্টল করা প্রতিটি provider তালিকাভুক্ত করে এবং বর্তমানে নির্বাচিতটিকে চিহ্নিত করে। কোনো package ইনস্টল করা আছে মানেই সেটি নির্বাচিত—এমন নয়। তাই package list নয়, selection পড়ুন।

Transition চলাকালে উভয় implementation-ই package হিসেবে সরবরাহ করা হয়েছে। Rust-ভিত্তিকটি হলো sudo-rs; August 2026 অনুযায়ী 26.04-এ এর version 0.2.13। Todd C. Miller রক্ষণাবেক্ষণ করা মূল implementation-টি এখনও sudo package। পরিবর্তনটি হলো, এর program-গুলোর সঙ্গে একটি .ws suffix যুক্ত হয়েছে, যাতে উভয়টি একই সঙ্গে ইনস্টল করা যায়: /usr/bin/sudo.ws এবং /usr/bin/visudo.ws, পাশাপাশি cvtsudoers.ws এবং sudoreplay.ws। September 2026-এ 26.04 archive দিয়ে যাচাই করা হয়েছে: dpkg -L sudo suffix-যুক্ত binary-গুলো তালিকাভুক্ত করে, এবং sudo-rs সেগুলোর পাশে /usr/bin/sudo-rs সরবরাহ করে।

Ubuntu কেন sudo-rs-এ পরিবর্তন করেছে

sudo setuid root হিসেবে চলে। সিস্টেমের যেকোনো user এটি চালু করতে পারে, এবং এটি পূর্ণ privilege নিয়ে শুরু হয়। তাই এর ভেতরের একটি memory bug-ও local root exploit-এ পরিণত হতে পারে। CVE-2021-3156 ঠিক এমনই একটি সমস্যা ছিল। যেকোনো local user এই heap buffer overflow-এ পৌঁছাতে পারত, এবং এটি প্রায় দশ বছর released code-এ রয়ে গিয়েছিল। Rust compile time-এ এই ধরনের bug শনাক্ত করে। Rewrite করার মূল কারণ এটিই।

দ্বিতীয় কারণটি হলো scope, এবং আপনার config-এর সঙ্গে সরাসরি সম্পর্কিত কারণ এটিই। মূল sudo গত তিন দশকে অনেক feature সংগ্রহ করেছে। প্রতিটি feature root হিসেবে চলা আরও code যোগ করে। sudo-rs ইচ্ছাকৃতভাবে এর একটি subset বাস্তবায়ন করে। এর নির্মাতারা যেসব feature-কে niche বা সক্রিয়ভাবে ক্ষতিকর মনে করেছেন, সেগুলো বাদ দিয়েছেন। তাই বছরের পর বছর কাজ করা কোনো sudoers construct এখানে সম্পূর্ণ অনুপস্থিত থাকতে পারে। আপনার wildcard rule এমনই একটি construct।

Memory safety একটি নির্দিষ্ট শ্রেণির bug দূর করে। এতে কোনো program সম্পূর্ণ bug মুক্ত হয় না, এবং default হওয়ার পর sudo-rs নিজস্ব security fix-ও প্রকাশ করেছে। অন্য যেকোনো software-এর মতো এটিতেও patch প্রয়োগ করুন।

কোন sudoers rule এখনও কাজ করে

ফাইলটি একই। sudo-rs /etc/sudoers এবং /etc/sudoers.d/-এর drop-in file পড়ে। একজন server operator সাধারণত যে rule লেখেন, সেগুলো সমর্থিত:

• deploy ALL=(ALL:ALL) ALL এবং %sudo ALL=(ALL:ALL) ALL-এর মতো group form
• NOPASSWD: এবং PASSWD: tag
• User_Alias, Runas_Alias, Host_Alias এবং Cmnd_Alias
• নির্দিষ্ট argument list-সহ command, যেমন /usr/bin/systemctl restart app-api
• ""-সহ command। এতে command-টি কোনো argument ছাড়া চালানো যায়
• শেষ argument হিসেবে *-সহ command। এতে পরবর্তী যেকোনো argument অনুমোদিত হয়
• /-এ শেষ হওয়া directory path। এতে ওই directory-এর যেকোনো command অনুমোদিত হয়
• একটি list থেকে command বাদ দিতে !
• Defaults-এর একটি কার্যকর subset। এর মধ্যে secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw এবং use_pty অন্তর্ভুক্ত

দুটি default-এর আচরণ আলাদা এবং এগুলো অনেক সময় সমস্যা তৈরি করে। sudo-rs-এ env_reset বন্ধ করা যায় না; এটি সবসময় চালু থাকে। use_pty default হিসেবে চালু থাকে, তাই command-টি নিজস্ব pseudo-terminal-এ চলে।

আপনার wildcard sudoers rule আর কেন মেলেনি

Wildcard এখনও একটি জায়গায় ব্যবহার করা যায়: command-এর file name-এ। %ops ALL = /sbin/fsck*-এর একটি rule এখনও sudo fsck এবং sudo fsck_exfat অনুমোদন করে, কারণ * হলো filesystem-এর সঙ্গে মিলিয়ে দেখা path-এর অংশ।

Argument list-এর ভিতরে sudo-rs কেবল দুটি বিশেষ form গ্রহণ করে, এবং কোনোটিই pattern নয়। ""-এর অর্থ কোনো argument নেই। শেষে থাকা *-এর অর্থ যেকোনো পরবর্তী argument। অন্য সব argument literal text হিসেবে তুলনা করা হয়। তাই %ops ALL = /sbin/service ntp * সঠিক, কারণ ntp literal এবং * শেষে রয়েছে। কিন্তু নিচের মতো একটি rule আপনার প্রত্যাশিত কোনো অনুমতিই দেয় না:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app-*

app-* একটি argument-এর মাঝখানে থাকা pattern। sudo-rs এটিকে expand করে না। তাই rule-টি systemctl restart app-api-এর ক্ষেত্রে প্রযোজ্য হয় না এবং sudo command প্রত্যাখ্যান করে। আপনার নিজের server-এর যেকোনো rule সম্পর্কে প্রকৃত অবস্থা জানার জন্য দুটি command ব্যবহার করুন: root হিসেবে চালানো sudo -l -U deploy দেখায় ওই account আসলে কোন command চালাতে পারে, আর sudo visudo -c জানায় file-টি আদৌ parse করা যায় কি না। এলোমেলোভাবে editing শুরু করার আগে command দুটি চালান।

Wildcard নিয়মটি শুরু থেকেই একটি নিরাপত্তা ফাঁক ছিল

মূল sudo-তে আপনি যে argument লেখেন, সেগুলো একটি string হিসেবে জোড়া হয়। এরপর glob ব্যবহার করে সেই string-কে নিয়মের argument string-এর সঙ্গে মিলিয়ে দেখা হয়। Glob whitespace-ও মেলাতে পারে। প্রায় সবাই এই বিষয়টি এড়িয়ে যান।

sudo-rs documentation-এ এর সবচেয়ে স্পষ্ট উদাহরণ আছে। /bin/rm *.txt নিয়মটি sudo rm -rf /home .txt-কেও অনুমোদন করে, কারণ একমাত্র * -rf /home -কে গিলে ফেলে এবং জোড়া string-টি এখনও .txt দিয়ে শেষ হয়। নিয়মটি পড়লে মনে হয়, “শুধু text file”। কিন্তু এর অর্থ দাঁড়ায়, “যেকোনো argument চলবে, যদি পুরো line .txt দিয়ে শেষ হয়।”

systemctl উদাহরণেও একই বিষয় প্রযোজ্য। Argument-গুলো একটি joined string হিসেবে তুলনা করা হয়। তাই শেষে থাকা pattern-এর পরে আপনি যা যোগ করেন, trailing pattern সেটিও মেলাতে পারে। ফলে restart app-*, restart app-api এবং caller-এর যোগ করা অতিরিক্ত যেকোনো argument-কে অনুমোদন করে। কোনো argument-এর ভেতরে pattern ব্যবহার করলে তার আশপাশের argument-গুলোর নিয়ন্ত্রণও ছেড়ে দেওয়া হয়। অথচ একটি command-এর ক্ষমতা মূলত argument-গুলোর মধ্যেই থাকে। sudo-rs এই গঠনকে নিরাপদ করার চেষ্টা না করে সরাসরি প্রত্যাখ্যান করে, কারণ এর কোনো সাধারণ নিরাপদ রূপ নেই।

Wildcard-এর বদলে স্পষ্ট command list ব্যবহার করুন

বেশিরভাগ wildcard rule তৈরি হয় কারণ কেউ চারটি line লিখতে চাননি। চারটি line-ই লিখুন।

Cmnd_Alias APP_RESTART = /usr/bin/systemctl restart app-api, /usr/bin/systemctl restart app-worker
Cmnd_Alias APP_STATUS = /usr/bin/systemctl status app-api, /usr/bin/systemctl status app-worker
deploy ALL=(root) NOPASSWD: APP_RESTART, APP_STATUS

সঠিক path ব্যবহার করুন। binary যেখানে /usr/bin/systemctl, সেখানে /bin/systemctl উল্লেখ করা rule কখনো match করবে না। এই ব্যর্থতা permissions সমস্যার মতোই দেখায়। command -v systemctl দিয়ে নিশ্চিত করুন এবং এটি যা দেখায় তা paste করুন।

rule-টি /etc/sudoers-এ না দিয়ে আলাদা drop-in file-এ রাখুন। এতে package upgrade আপনার edit-এর সঙ্গে আর বিরোধ করবে না:

sudo visudo -f /etc/sudoers.d/90-deploy
sudo visudo -c
sudo -l -U deploy

file-এর নামের মধ্যে dot বা শেষে tilde রাখবেন না। মূল sudo sudoers.d-এর যেসব file-এর নামে dot আছে, সেগুলো উপেক্ষা করে। তাই 90-deploy.conf একটি প্রচলিত silent no-op। এই convention মেনে চললে কোনো অতিরিক্ত অসুবিধা নেই।

তালিকাটি দীর্ঘ হলে root-মালিকানাধীন wrapper ব্যবহার করুন

অনুমোদিত সেটটি তালিকাভুক্ত করার জন্য খুব বড় হলে, সিদ্ধান্তটি sudoers-এর বাইরে সরিয়ে root-এর মালিকানাধীন একটি ছোট প্রোগ্রামে রাখুন।

sudo tee /usr/local/sbin/app-restart >/dev/null <<'EOF'
#!/bin/sh
set -eu
case "${1:-}" in
  app-api|app-worker) ;;
  *) echo "app-restart: not allowed: ${1:-}" >&2; exit 1 ;;
esac
exec /usr/bin/systemctl restart "$1"
EOF
sudo chown root:root /usr/local/sbin/app-restart
sudo chmod 0755 /usr/local/sbin/app-restart
ls -l /usr/local/sbin/app-restart

এরপর sudoers অংশে শুধু একটি command উল্লেখ করুন:

deploy ALL=(root) NOPASSWD: /usr/local/sbin/app-restart *

শেষের * এখানে গ্রহণযোগ্য, কারণ কী অনুমোদিত হবে তা sudo নয়, script নির্ধারণ করে। তবে এটি কেবল তখনই নিরাপদ, যখন script-টির মালিক root এবং অন্য কেউ এতে লিখতে পারে না। deploy যদি file-টিতে লিখতে পারে, তাহলে deploy এর বিষয়বস্তু বদলে দিয়ে root হিসেবে যেকোনো কিছু চালাতে পারবে। আপনি যে wildcard rule সরিয়েছেন, এটি তার চেয়েও বিপজ্জনক। ls -l দিয়ে mode পরীক্ষা করুন। output আপনার কাছে স্পষ্ট না হলে drwxr-xr-x permission string পড়তে শিখতে পাঁচ মিনিটই লাগে। একই নিয়ম directory-এর ক্ষেত্রেও প্রযোজ্য: /usr/local/sbin account-টির জন্য writable হওয়া চলবে না, কারণ writable directory থাকলে সম্পূর্ণ file-টি প্রতিস্থাপন করা যায়।

sudo rule ব্যবহার না করে কাজটির জন্য আলাদা account দিন

প্রথমে বরং প্রশ্ন করুন, কমান্ডটির আদৌ root প্রয়োজন কি না। কোনো service নিজের user হিসেবে চললে সেই user দিয়েই এটি পরিচালনা করা যায় এবং sudoers-এ কোনো line প্রয়োজন হয় না। system unit-এর ক্ষেত্রে systemd ইতিমধ্যেই এই সিদ্ধান্ত polkit-এর কাছে অর্পণ করে। তাই একটি rule-এ নির্দিষ্ট একটি unit এবং একজন operator-এর নাম দেওয়া যায়:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "app-api.service" &&
        subject.user == "deploy") {
        return polkit.Result.YES;
    }
});

এটি /etc/polkit-1/rules.d/50-app-api.rules হিসেবে সংরক্ষণ করুন। এরপর deploy কোনো sudo ছাড়াই systemctl restart app-api চালাতে পারবে। যে নির্দিষ্ট context এটি ব্যবহার করবে, ঠিক সেখান থেকে পরীক্ষা করুন। কারণ SSH session-এ কাজ করা কোনো rule-এর ওপর নির্ভর করার আগে cron থেকে সেটি নিশ্চিত করা দরকার। যেভাবেই হোক, কাজটি যে account করবে সেটি শুধু ওই কাজের জন্যই থাকা উচিত। VPS-এ সর্বনিম্ন privilege-যুক্ত user account ব্যবহারের পেছনেও একই যুক্তি রয়েছে।

sudo-rs-এ আর যা নেই

sudo -E বাস্তবায়িত হয়নি। এর পরিবর্তে প্রয়োজনীয় ভেরিয়েবলগুলোর নাম Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" দিয়ে দিন। মনে রাখবেন, env_reset সব সময় চালু থাকে। তাই সংরক্ষণ না করা যেকোনো বিষয় মুছে যায়।

LDAP-এ কেন্দ্রীয় sudoers সংরক্ষণ আর নেই। sudoers.ldap এবং cvtsudoers বাস্তবায়িত হয়নি, এবং sudo-ldap package-টি 26.04-এ অপসারণ করা হয়েছে। PAM বা SSSD-এর মাধ্যমে LDAP authentication এখনও কাজ করে। তবে directory-তে policy সংরক্ষণের অংশটি এই পরিধির বাইরে।

অনুমোদিত command থেকে shell escape বন্ধ করার চেষ্টা করা INTERCEPT বাস্তবায়িত হয়নি। নির্ধারিত কোনো ব্যবহারকারীর বিরুদ্ধে এটি এমনিতেও কার্যকর ছিল না। কোনো rule যদি কাউকে root হিসেবে editor বা interpreter চালানোর অনুমতি দেয়, তাহলে তার root access আছে। কোনো sudo option এটি পরিবর্তন করতে পারে না।

Session recording বাস্তবায়িত হয়নি। তাই কোনো I/O log বা sudoreplay নেই। Logging শুধু syslog-এ যায়। এটি অন্য কোথাও পাঠানোর জন্য logfile option-ও নেই। ফলে sudo message আপনার system যেখানেই syslog পাঠায়, সেখানেই জমা হবে।

sudo.ws-এ কি আবার ফিরে যাবেন?

যেতে পারেন, এবং 26.04 cycle-এ মূল প্যাকেজটি এই কারণেই রাখা হয়েছে।

sudo apt install sudo
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

এই পৃষ্ঠার বদলে --config output থেকে exact path কপি করুন, কারণ আপনার নিজের system যে তালিকা গ্রহণ করবে, সেটি ওই output-এই আছে। পরে sudo-rs-এ ফিরে যেতে হলে একই তালিকা থেকে sudo-rs binary path-এ alternative সেট করুন।

sudo-কে প্রভাবিত করে এমন কোনো পরিবর্তন করার আগে দ্বিতীয় একটি SSH session খোলা রাখুন, সেখানে লগ ইন করে idle অবস্থায় থাকুন। যে sudoers file parse হয় না, অথবা এমন binary-র দিকে alternative নির্দেশ করে যা installed নেই, সেটি remote box-এ আপনাকে root হওয়ার সব পথ বন্ধ করে দিতে পারে। নতুন VPS-এ প্রথম দশ মিনিটে যা যা করেন, এই অভ্যাসটিও তার অংশ হওয়া উচিত।

এই switch back-কে fix হিসেবে নয়, একটি deadline হিসেবে দেখুন। এটি আপনাকে rules সঠিকভাবে নতুন করে লেখার জন্য এক সপ্তাহ সময় দেয়। সেই rewrite নিজের কারণেই করা উচিত, কারণ আপনি যে প্রতিটি wildcard rule মুছে ফেলেন, সেটি তার লেখক যতটা বুঝেছিলেন তার চেয়ে বেশি অনুমতি দিচ্ছিল।

FAQ

Ubuntu 26.04-এ আমার sudoers wildcard rule কাজ করা বন্ধ করল কেন?

কারণ Ubuntu 26.04 LTS ডিফল্ট sudo হিসেবে sudo-rs নির্বাচন করে, আর sudo-rs কোনো command-এর arguments-এর ভেতরের wildcard pattern মেলায় না। এটি command-এর file name-এ wildcard, no arguments বোঝাতে "" এবং শেষ argument হিসেবে একটি * গ্রহণ করে। /usr/bin/systemctl restart app-*-এর মতো rule argument-এর মাঝখানে একটি pattern রাখে। তাই এটি কোনো অনুমতি দেয় না এবং command প্রত্যাখ্যাত হয়। Account-টির প্রকৃত অনুমতিগুলো দেখতে root হিসেবে sudo -l -U deploy চালান। এরপর rule-টি exact command অথবা root-owned wrapper script দিয়ে প্রতিস্থাপন করুন।

Ubuntu 26.04-এ মূল sudo-তে কীভাবে ফিরে যাব?

মূল sudo sudo package-এ থাকে। এর binary-গুলোর শেষে .ws suffix থাকে। sudo apt install sudo দিয়ে এটি install করুন। এরপর sudo update-alternatives --set sudo /usr/bin/sudo.ws দিয়ে alternative-টি সেট করুন। আপনার system-এ উপলভ্য exact path পড়তে আগে update-alternatives --config sudo চালান। পরিবর্তন করার সময় একটি দ্বিতীয় SSH session খোলা রাখুন। এতে sudo-ldap ফিরে আসে না। আপনি যে implementation-ই নির্বাচন করুন, 26.04 থেকে এটি সরিয়ে দেওয়া হয়েছে।

sudo-rs কি একই /etc/sudoers file পড়ে?

হ্যাঁ। sudo-rs /etc/sudoers এবং /etc/sudoers.d/-এর অধীন drop-in file-গুলো পড়ে। Users, groups, aliases, run-as specification এবং NOPASSWD tag-এর জন্য একই syntax ব্যবহৃত হয়। এটি sudoers language-এর একটি subset implement করে। তাই পার্থক্যগুলো সাধারণত ভিন্ন আচরণ হিসেবে নয়, বরং অনুপস্থিত construct হিসেবে দেখা যায়। sudo visudo দিয়ে edit করুন। Session বন্ধ করার আগে sudo visudo -c দিয়ে যাচাই করুন।

sudo-rs-এ sudo -E-এর পরিবর্তে কী ব্যবহার করা হয়?

sudo -E implement করা হয়নি। মূল sudo-তেও এটি নিরুৎসাহিত করা হতো। কারণ caller নিয়ন্ত্রণ করে এমন environment root process-এ দিলে process-টির আচরণ পরিবর্তন করার একটি সুপরিচিত সুযোগ তৈরি হয়। sudoers-এ আপনার প্রয়োজনীয় variable-গুলোর নাম নির্দিষ্ট করুন। উদাহরণ হিসেবে Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY"-এর মতো একটি line ব্যবহার করুন। sudo-rs-এ env_reset সবসময় চালু থাকে এবং এটি disabled করা যায় না। তাই যেসব variable আপনি রাখবেন না, সেগুলো সব clear করা হবে।