Ubuntu 26.04 میں sudo-rs اور sudoers میں کیا بدلا؟

Ubuntu پر sudo-rs میں کیا تبدیلیاں آتی ہیں

Ubuntu 26.04 LTS میں sudo-rs بطور default sudo شامل ہے، اس لیے نئے server پر sudo command چلانے سے اصل C program کے بجائے Rust کی دوبارہ تیار کردہ implementation چلتی ہے۔ زیادہ تر sudoers files پہلے کی طرح بالکل کام کرتی رہتی ہیں۔ جو rule متاثر ہوتا ہے وہ وہ ہے جس میں command کے arguments کے اندر wildcard شامل ہو، کیونکہ sudo-rs argument text کے خلاف glob patterns match نہیں کرتا۔

Ubuntu 25.10 نے یہ تبدیلی پہلے کی تھی اور Ubuntu 26.04 LTS میں بھی اسے برقرار رکھا گیا ہے۔ Ubuntu 24.04 LTS متاثر نہیں ہوتا، کیونکہ جب تک آپ sudo-rs کو دستی طور پر install نہ کریں، وہ اصل sudo ہی منتخب کرتا ہے۔ یہ تبدیلی اس وقت اہم ہوتی ہے جب آپ Ubuntu 24.04 سے 26.04 پر upgrade کریں، یا نئی release پر نیا server بنائیں۔ اگر آپ interim releases بھی چلاتے ہیں تو server پر LTS اور interim Ubuntu releases میں فرق سے معلوم ہوتا ہے کہ اس جیسی تبدیلی سے کون سی machine پہلے متاثر ہوتی ہے۔

معلوم کریں کہ آپ کا سرور حقیقت میں کون سا sudo چلا رہا ہے

اس کا فیصلہ release number سے نہ کریں۔ مشین سے براہِ راست معلوم کریں۔

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

اپنے box پر موجود sudo --version پر، انٹرنیٹ کی کسی بھی version table کے مقابلے میں زیادہ اعتماد کریں، اس صفحے کے مقابلے میں بھی۔ update-alternatives --config sudo جواب کا دوسرا حصہ ہے: یہ /usr/bin/sudo کے ہر installed provider کی فہرست دیتا ہے اور منتخب provider کی نشان دہی کرتا ہے۔ کسی package کا installed ہونا اور اس کا selected ہونا ایک ہی بات نہیں، اس لیے package list نہیں بلکہ selection پڑھیں۔

transition کے دوران دونوں implementations package کی صورت میں دستیاب ہیں۔ Rust والی implementation sudo-rs ہے، جو August 2026 تک 26.04 میں version 0.2.13 پر ہے۔ Todd C. Miller کی برقرار رکھی ہوئی اصل implementation اب بھی sudo package ہے؛ تبدیلی صرف یہ ہے کہ اس کے programs کے ساتھ .ws suffix لگا ہوتا ہے، تاکہ دونوں کو ایک وقت میں install کیا جا سکے: /usr/bin/sudo.ws اور /usr/bin/visudo.ws، نیز cvtsudoers.ws اور sudoreplay.ws۔ September 2026 میں 26.04 archive کے خلاف تصدیق کی گئی: dpkg -L sudo suffixed binaries کی فہرست دیتا ہے، اور sudo-rs ان کے ساتھ /usr/bin/sudo-rs فراہم کرتا ہے۔

Ubuntu نے sudo-rs کیوں اختیار کیا

sudo، setuid root ہے۔ سسٹم کا کوئی بھی user اسے شروع کر سکتا ہے، اور یہ مکمل privileges کے ساتھ شروع ہوتا ہے۔ اس لیے اس کے اندر موجود memory bug، local root exploit بن جاتا ہے۔ CVE-2021-3156 بھی یہی تھا: heap buffer overflow جس تک کوئی بھی local user پہنچ سکتا تھا، اور یہ تقریباً دس سال تک released code میں موجود رہا۔ Rust اس قسم کے bug کو compile time پر پکڑ لیتا ہے۔ rewrite کی بنیادی وجہ یہی ہے۔

دوسری وجہ scope ہے، اور یہی آپ کی config پر اثر انداز ہوتی ہے۔ اصل sudo نے تین دہائیوں کے دوران features کا بڑا مجموعہ اکٹھا کر لیا ہے، اور ہر feature root کے طور پر چلنے والے مزید code کا اضافہ کرتا ہے۔ sudo-rs جان بوجھ کر اس کا subset implement کرتا ہے۔ اس کے authors نے جن چیزوں کو niche یا actively harmful سمجھا، انہیں شامل نہیں کیا۔ اس لیے sudoers کا وہ construct جو برسوں سے کام کر رہا تھا، مکمل طور پر absent ہو سکتا ہے۔ آپ کا wildcard rule بھی انہی میں سے ایک ہے۔

Memory safety ایک قسم کے bug کو ختم کرتی ہے۔ اس کا مطلب یہ نہیں کہ program میں کوئی bug نہیں رہتا، اور default بننے کے بعد sudo-rs کے اپنے security fixes بھی جاری ہوئے ہیں۔ اسے بھی ہر دوسرے software کی طرح patch کریں۔

کون سے sudoers قواعد اب بھی کام کرتے ہیں

یہ وہی فائل ہے۔ sudo-rs /etc/sudoers اور /etc/sudoers.d/ میں موجود drop-in فائلوں کو پڑھتا ہے، اور سرور آپریٹر کے عام طور پر لکھے جانے والے قواعد supported ہیں:

• deploy ALL=(ALL:ALL) ALL اور گروپ کی صورتیں، جیسے %sudo ALL=(ALL:ALL) ALL
• NOPASSWD: اور PASSWD: tags
• User_Alias، Runas_Alias، Host_Alias اور Cmnd_Alias
• عین arguments کی فہرست والی command، مثلاً /usr/bin/systemctl restart app-api
• "" کے بعد آنے والی command، جو command کو صرف اس وقت اجازت دیتی ہے جب اس کے ساتھ کوئی argument نہ ہو
• آخری argument کے طور پر * کے بعد آنے والی command، جو آخر میں آنے والے کسی بھی arguments کی اجازت دیتی ہے
• / پر ختم ہونے والا directory path، جو اس directory میں موجود کسی بھی command کی اجازت دیتا ہے
• !، جو فہرست میں سے کسی command کو خارج کرنے کے لیے استعمال ہوتا ہے
• Defaults کا مفید subset، جس میں secure_path، env_keep، env_check، timestamp_timeout، passwd_tries، editor، umask، targetpw، rootpw اور use_pty شامل ہیں

دو defaults مختلف انداز میں کام کرتے ہیں اور اکثر صارفین کو الجھن میں ڈالتے ہیں۔ sudo-rs میں env_reset کو بند نہیں کیا جا سکتا؛ یہ ہمیشہ فعال رہتا ہے۔ use_pty بطور default فعال ہے، اس لیے command اپنے pseudo-terminal میں چلتی ہے۔

آپ کا wildcard sudoers rule match کرنا کیوں بند ہو گیا

Wildcards اب بھی ایک جگہ allowed ہیں: command کے file name میں۔ %ops ALL = /sbin/fsck* کا rule اب بھی sudo fsck اور sudo fsck_exfat کی اجازت دیتا ہے، کیونکہ * اس path کا حصہ ہے جسے filesystem کے خلاف match کیا جا رہا ہے۔

Argument list کے اندر sudo-rs صرف دو special forms قبول کرتا ہے، اور ان میں سے کوئی بھی pattern نہیں ہے۔ "" کا مطلب ہے کہ کوئی argument نہیں ہے۔ آخر میں * کا مطلب ہے کہ اس کے بعد آنے والے تمام arguments قبول ہیں۔ ہر دوسرے 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 کو cover نہیں کرتا اور sudo command کو مسترد کر دیتا ہے۔ اپنے server پر کسی بھی rule کی اصل صورت جاننے کے لیے دو commands استعمال کریں: sudo -l -U deploy کو root کے طور پر چلانے سے معلوم ہوتا ہے کہ اس account کو حقیقت میں کون سی commands چلانے کی اجازت ہے، اور sudo visudo -c بتاتا ہے کہ file درست طور پر parse ہوتی بھی ہے یا نہیں۔ بے ترتیب editing شروع کرنے سے پہلے انہیں چلائیں۔

وائلڈ کارڈ کا اصول ہمیشہ ایک خلا تھا

اصل sudo میں آپ کے درج کردہ arguments کو ایک string میں جوڑا جاتا ہے، پھر انہیں glob کے ذریعے rule کی argument string سے ملایا جاتا ہے۔ glob whitespace سے بھی match کرتا ہے۔ تقریباً ہر شخص اسی حصے کو نظرانداز کر دیتا ہے۔

sudo-rs کی documentation اس کی سب سے واضح مثال پیش کرتی ہے۔ /bin/rm *.txt کا rule sudo rm -rf /home .txt کو بھی اجازت دیتا ہے، کیونکہ ایک *، -rf /home کو نگل لیتا ہے اور جوڑی گئی string پھر بھی .txt پر ختم ہوتی ہے۔ بظاہر rule کہتا ہے: "صرف text files"۔ حقیقت میں اس کا مطلب ہے: "کوئی بھی arguments، بشرطیکہ line .txt پر ختم ہو"۔

یہی بات systemctl کی مثال پر بھی لاگو ہوتی ہے۔ چونکہ arguments کو ایک joined string کے طور پر compare کیا جاتا ہے، اس لیے آخر میں موجود pattern اس کے بعد شامل کیے گئے ہر متن سے بھی match کر جاتا ہے۔ چنانچہ restart app-*، restart app-api کے ساتھ caller کے شامل کردہ مزید arguments کو بھی قبول کرتا ہے۔ کسی argument کے اندر موجود pattern اس کے اردگرد کے arguments کو غیر محفوظ کر دیتا ہے، جبکہ command کی اصل طاقت arguments میں ہوتی ہے۔ sudo-rs اس construct کو محفوظ بنانے کی کوشش کرنے کے بجائے مسترد کر دیتا ہے، کیونکہ اس کی کوئی عمومی محفوظ شکل موجود نہیں۔

وائلڈ کارڈ کو واضح command list سے تبدیل کریں

زیادہ تر وائلڈ کارڈ rules اس لیے موجود ہوتے ہیں کہ کسی نے چار lines لکھنے سے گریز کیا تھا۔ چاروں lines لکھیں۔

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 درست رکھیں۔ جس system پر binary /usr/bin/systemctl میں موجود ہو، وہاں /bin/systemctl کا نام دینے والا rule کبھی match نہیں ہوتا، اور اس کی failure بالکل permissions کے مسئلے جیسی دکھائی دیتی ہے۔ command -v systemctl سے تصدیق کریں اور اس کا output شامل کریں۔

rule کو /etc/sudoers میں رکھنے کے بجائے اپنی الگ drop-in file میں رکھیں، تاکہ package upgrade آپ کی ترمیم سے متصادم نہ ہو:

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

file کا نام dot کے بغیر اور آخر میں tilde کے بغیر رکھیں۔ اصل sudo sudoers.d میں ان files کو نظرانداز کرتا ہے جن کے نام میں dot ہو۔ اس لیے 90-deploy.conf ایک عام silent no-op ہے، اور convention برقرار رکھنے میں کوئی اضافی محنت نہیں لگتی۔

فہرست طویل ہو جائے تو root کی ملکیت والا wrapper استعمال کریں

جب allowed set اتنا بڑا ہو کہ اسے درج کرنا مشکل ہو، تو یہ فیصلہ sudoers سے نکال کر ایک ایسے مختصر program میں منتقل کریں جس کی ملکیت 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 کے پاس ہو اور کوئی دوسرا اسے writable نہ بنا سکے۔ اگر deploy فائل میں لکھ سکتا ہو تو deploy اس کا مواد تبدیل کرکے root کے طور پر کوئی بھی command چلا سکتا ہے۔ یہ اس wildcard rule سے بھی زیادہ خطرناک ہے جسے آپ نے ہٹایا تھا۔ ls -l سے mode چیک کریں۔ اگر output آپ کے لیے واضح نہ ہو تو drwxr-xr-x permission string پڑھنا سیکھنے میں پانچ منٹ لگتے ہیں۔ یہی rule directory پر بھی لاگو ہوتا ہے: /usr/local/sbin account کے لیے writable نہیں ہونا چاہیے، کیونکہ writable directory کا مطلب ہے کہ فائل کو مکمل طور پر تبدیل کیا جا سکتا ہے۔

کام کے لیے الگ account استعمال کریں، sudo rule نہیں

اکثر بہتر سوال یہ ہوتا ہے کہ command کو root کی ضرورت ہی کیوں ہے۔ جو service اپنے user کے طور پر چلتی ہے، اسے وہی user manage کر سکتا ہے، اور sudoers میں کسی line کی ضرورت نہیں رہتی۔ system units کے لیے 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، systemctl restart app-api کو sudo کے بغیر چلا سکتا ہے۔ اسے اسی context سے test کریں جس میں اسے استعمال کیا جائے گا، کیونکہ جو rule آپ کے SSH session میں کام کرتا ہے، اسے cron سے بھی آزمانا ضروری ہے، اس سے پہلے کہ آپ اس پر انحصار کریں۔ بہرحال، کام کرنے والا account صرف اسی کام کے لیے موجود ہونا چاہیے۔ یہی اصول VPS پر کم سے کم مراعات والے user accounts کے پیچھے بھی ہے۔

sudo-rs میں مزید کیا شامل نہیں ہے

sudo -E نافذ نہیں کیا گیا۔ اس کے بجائے مطلوبہ variables کو Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" کے ساتھ نامزد کریں، اور یاد رکھیں کہ env_reset ہمیشہ فعال ہے، اس لیے جو کچھ محفوظ نہیں رکھا جاتا اسے صاف کر دیا جاتا ہے۔

LDAP میں مرکزی sudoers storage ختم کر دی گئی ہے۔ sudoers.ldap اور cvtsudoers نافذ نہیں کیے گئے، اور sudo-ldap package کو 26.04 میں ہٹا دیا گیا تھا۔ PAM یا SSSD کے ذریعے LDAP authentication اب بھی کام کرتی ہے۔ دائرۂ کار سے باہر صرف directory میں policy رکھنے کا حصہ ہے۔

INTERCEPT، جس کا مقصد مجاز command سے shell escapes روکنا تھا، نافذ نہیں کیا گیا۔ ویسے بھی یہ پُرعزم user کے خلاف مؤثر نہیں تھا۔ اگر کوئی rule کسی شخص کو root کے طور پر editor یا interpreter چلانے کی اجازت دیتا ہے تو اسے root access حاصل ہے، اور sudo کا کوئی option اس حقیقت کو تبدیل نہیں کرتا۔

Session recording نافذ نہیں کی گئی، اس لیے کوئی I/O log اور کوئی sudoreplay موجود نہیں ہے۔ Logging صرف syslog کو بھیجی جاتی ہے، اور اسے کسی دوسری جگہ redirect کرنے کے لیے logfile option بھی موجود نہیں ہے۔ اس لیے sudo messages اسی جگہ پہنچتے ہیں جہاں آپ کا system پہلے ہی syslog بھیجتا ہے۔

کیا آپ کو sudo.ws پر واپس جانا چاہیے؟

آپ ایسا کر سکتے ہیں، اور 26.04 cycle کے دوران اصل sudo پیکیج میں شامل رہتا ہے، خاص طور پر اسی وجہ سے۔

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

--config کے output سے exact paths نقل کریں، اس صفحے سے نہیں، کیونکہ آپ کا اپنا system اسی فہرست کو قبول کرے گا۔ بعد میں sudo-rs پر واپس جانے کے لیے اسی فہرست میں موجود sudo-rs binary path کو alternative کے طور پر set کریں۔

sudo کو متاثر کرنے والی کسی بھی تبدیلی سے پہلے دوسری SSH session کھلی رکھیں، اس میں login کریں اور اسے idle چھوڑ دیں۔ ایسا sudoers file جو parse نہ ہو، یا ایسا alternative جو installed نہ ہونے والے binary کی طرف اشارہ کرے، آپ کو remote box پر root بننے کے کسی طریقے سے محروم کر سکتا ہے۔ یہ عادت ان تمام کاموں کا حصہ ہونی چاہیے جو آپ نئے VPS کے پہلے دس منٹ میں کرتے ہیں۔

اس واپسی کو fix کے بجائے deadline سمجھیں۔ اس سے آپ کو rules درست طریقے سے دوبارہ لکھنے کے لیے ایک ہفتہ مل جاتا ہے۔ یہ rewrite اپنی جگہ بھی ضروری ہے، کیونکہ ہر wildcard rule جسے آپ حذف کرتے ہیں، اپنے مصنف کے ارادے سے زیادہ اختیارات دے رہا تھا۔

FAQ

میرے sudoers وائلڈ کارڈ rule نے Ubuntu 26.04 پر کام کرنا کیوں بند کر دیا؟

کیونکہ Ubuntu 26.04 LTS میں sudo-rs کو default sudo کے طور پر منتخب کیا گیا ہے، اور sudo-rs کمانڈ کے arguments کے اندر wildcard patterns کو match نہیں کرتا۔ یہ کمانڈ کے file name میں wildcard کی اجازت دیتا ہے، "" کا مطلب ہے کہ کوئی argument نہیں، اور صرف ایک * کو آخری argument کے طور پر قبول کرتا ہے۔ /usr/bin/systemctl restart app-* جیسا rule کسی argument کے درمیان pattern رکھتا ہے، اس لیے یہ کوئی اجازت نہیں دیتا اور کمانڈ مسترد ہو جاتی ہے۔ account کو حقیقتاً حاصل اجازتیں دیکھنے کے لیے root کے طور پر sudo -l -U deploy چلائیں، پھر rule کو exact commands یا root-owned wrapper script سے تبدیل کریں۔

Ubuntu 26.04 پر میں original sudo پر واپس کیسے جاؤں؟

original sudo sudo package میں شامل ہے، جس کی binaries کے نام کے آخر میں .ws suffix ہوتا ہے۔ اسے sudo apt install sudo سے install کریں، پھر sudo update-alternatives --set sudo /usr/bin/sudo.ws کے ذریعے alternative کو اس binary کی طرف مقرر کریں۔ پہلے update-alternatives --config sudo چلائیں تاکہ آپ کے system پر دستیاب exact paths دیکھ سکیں، اور تبدیلی کے دوران دوسری SSH session کھلی رکھیں۔ اس سے sudo-ldap واپس نہیں آتا، کیونکہ implementation سے قطع نظر اسے 26.04 سے ہٹا دیا گیا ہے۔

کیا sudo-rs وہی /etc/sudoers file پڑھتا ہے؟

ہاں۔ sudo-rs /etc/sudoers اور /etc/sudoers.d/ کے تحت drop-in files پڑھتا ہے، اور users، groups، aliases، run-as specifications اور NOPASSWD tag کے لیے وہی syntax استعمال کرتا ہے۔ یہ sudoers language کے subset کو implement کرتا ہے، اس لیے فرق ان constructs کی صورت میں ظاہر ہوتا ہے جو موجود نہیں ہیں، نہ کہ ایسے constructs کی صورت میں جو مختلف انداز میں کام کرتے ہیں۔ sudo visudo سے edit کریں، پھر session بند کرنے سے پہلے sudo visudo -c سے تصدیق کریں۔

sudo-rs میں sudo -E کی جگہ کیا استعمال ہوتا ہے؟

sudo -E implemented نہیں ہے، اور original sudo میں بھی اس کی حوصلہ شکنی کی جاتی تھی، کیونکہ root process کو ایسا environment دینا جسے caller control کرتا ہو، اس process کے رویے کو بدلنے کا معروف طریقہ ہے۔ sudoers میں صرف وہ variables نامزد کریں جن کی واقعی ضرورت ہے، مثلاً Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" جیسی line کے ذریعے۔ sudo-rs میں env_reset ہمیشہ فعال رہتا ہے اور اسے disabled نہیں کیا جا سکتا، اس لیے ہر وہ variable صاف کر دیا جاتا ہے جسے آپ برقرار نہیں رکھتے۔