ద్వారా Matt Connor 2026-08-12 · అప్‌డేట్ చేయబడింది 2026-08-13

Ubuntu 26.04లో sudo-rs: sudoersలో ఏం మారుతుంది

Q: Ubuntu 26.04లో అసలు sudoకు తిరిగి ఎలా మారాలి?

అసలు sudo, sudo.wsగా package చేయబడింది. sudo apt install sudo.wsతో దాన్ని install చేయండి. తరువాత sudo update-alternatives --set sudo /usr/bin/sudo.wsతో alternativeను దానికి point చేయండి. ముందుగా update-alternatives --config sudo నడిపి మీ system అందించే ఖచ్చితమైన pathsను చూడండి. మార్పు చేస్తున్నప్పుడు రెండో SSH sessionను openలో ఉంచండి. మీరు ఏ implementationను ఎంచుకున్నా, ఇది sudo-ldapను తిరిగి తీసుకురాదు. అది 26.04లో తొలగించబడింది.

Q: 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ను close చేయడానికి ముందు sudo visudo -cతో verify చేయండి.

Q: sudo-rsలో sudo -E స్థానంలో ఏమి ఉపయోగిస్తారు?

sudo -E implement చేయబడలేదు. అసలు sudoలో కూడా ఇది ఇప్పటికే నిరుత్సాహపరచబడింది. ఎందుకంటే caller నియంత్రించే environmentను root processకు ఇవ్వడం, ఆ process ప్రవర్తించే విధానాన్ని మార్చడానికి తెలిసిన మార్గం. మీకు నిజంగా అవసరమైన variablesను sudoersలో స్పష్టంగా పేర్కొనండి. ఉదాహరణకు Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" వంటి lineను ఉపయోగించండి. sudo-rsలో env_reset ఎల్లప్పుడూ enabledగా ఉంటుంది. దాన్ని disable చేయలేరు. అందువల్ల మీరు ఉంచని ప్రతి variable clear చేయబడుతుంది.

Ubuntu 26.04లో sudo-rs డిఫాల్ట్ sudo అవుతుంది. sudoersలో wildcard argument rules ఇక match కావు. బదులుగా రాయాల్సిన rule, Ubuntu 24.04 ప్రభావం వివరాలు.

Ubuntuలో sudo-rs వల్ల మారే విషయాలు

Ubuntu 26.04 LTSలో sudo-rs డిఫాల్ట్ sudoగా వస్తుంది. అందువల్ల కొత్త serverలో sudo command అమలు చేస్తే అసలు C program బదులుగా Rustలో మళ్లీ అమలు చేసిన version నడుస్తుంది. చాలా sudoers files ఇంతకుముందులాగే పనిచేస్తాయి. అయితే command argumentsలో wildcard ఉన్న rule విఫలమవుతుంది. ఎందుకంటే 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*'

ఇంటర్నెట్‌లోని ఏ version table కంటే, ఈ పేజీతో సహా, మీ స్వంత యంత్రంలోని sudo --version ఫలితాన్ని విశ్వసించండి. update-alternatives --config sudo సమాధానంలోని మరో భాగం: ఇది /usr/bin/sudo కోసం ఇన్‌స్టాల్ చేసిన ప్రతి provider ను జాబితా చేసి, ఎంపికైనదాన్ని గుర్తిస్తుంది. Package ఇన్‌స్టాల్ అయి ఉండటం, అది ఎంపికై ఉండటంతో సమానం కాదు. కాబట్టి package list ను కాకుండా selection ను చదవండి.

Transition సమయంలో రెండు implementations package చేయబడ్డాయి. Rust implementation sudo-rs; August 2026 నాటికి 26.04 లో దీని version 0.2.13. Todd C. Miller నిర్వహించిన అసలు implementation sudo.ws గా package చేయబడింది. దాని programs కు .ws suffix ఉంటుంది: sudo.ws మరియు visudo.ws.

Ubuntu sudo-rs కు ఎందుకు మారింది

sudo setuid root తో నడుస్తుంది. సిస్టమ్‌లోని ఏ user అయినా దీన్ని ప్రారంభించగలరు. ఇది పూర్తి privileges తో ప్రారంభమవుతుంది. అందువల్ల ఇందులోని memory bug ఒక local root exploit కు దారితీయవచ్చు. CVE-2021-3156 కూడా ఇదే తరహా సమస్య. ఏ local user అయినా చేరుకోగల heap buffer overflow అందులో ఉంది. ఆ సమస్య విడుదలైన code లో సుమారు పది సంవత్సరాలు ఉండిపోయింది. Rust ఈ తరహా bug లను compile time లోనే గుర్తిస్తుంది. Rewrite కు ప్రధాన కారణం ఇదే.

రెండవ కారణం scope. ఇది మీ config పై ప్రభావం చూపుతుంది. అసలు sudo మూడు దశాబ్దాల్లో పెద్ద feature set ను సమకూర్చుకుంది. ప్రతి feature root గా నడిచే మరింత code ను సూచిస్తుంది. sudo-rs ఉద్దేశపూర్వకంగా కొంత భాగాన్ని మాత్రమే అమలు చేస్తుంది. Niche లేదా హానికరమైనవిగా దాని authors భావించిన అంశాలను చేర్చలేదు. అందువల్ల సంవత్సరాలుగా పనిచేసిన sudoers construct అందులో పూర్తిగా లేకపోవచ్చు. మీ wildcard rule వాటిలో ఒకటి.

Memory safety ఒక రకమైన bug ను తొలగిస్తుంది. దాంతో program లో ఎలాంటి bug ఉండదని కాదు. sudo-rs default అయిన తరువాత దానికీ security fixes విడుదలయ్యాయి. ఇతర software లాగే దీన్నీ patch చేయండి.

ఏ sudoers నియమాలు ఇప్పటికీ పనిచేస్తాయి

ఇది అదే ఫైల్. sudo-rs, /etc/sudoers మరియు /etc/sudoers.d/ లోని drop-in ఫైళ్లను చదువుతుంది. Server operator సాధారణంగా రాసే నియమాలకు మద్దతు ఉంది:

deploy ALL=(ALL:ALL) ALL, అలాగే %sudo ALL=(ALL:ALL) ALL వంటి group రూపాలు
NOPASSWD: మరియు PASSWD: tags
User_Alias, Runas_Alias, Host_Alias మరియు Cmnd_Alias
ఖచ్చితమైన argument list కలిగిన command, ఉదాహరణకు /usr/bin/systemctl restart app-api
"" తో ముగిసే command. ఇది arguments ఏవీ లేకుండా మాత్రమే ఆ command ను అనుమతిస్తుంది
చివరి argument గా * కలిగిన command. ఇది తరువాత వచ్చే ఏ arguments‌నైనా అనుమతిస్తుంది
/ తో ముగిసే directory path. ఇది ఆ directoryలోని ఏ command‌నైనా అనుమతిస్తుంది
జాబితా నుంచి ఒక command‌ను తొలగించడానికి !
Defaults లోని ఉపయోగకరమైన ఉపసమితి. ఇందులో secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw మరియు use_pty ఉన్నాయి

రెండు defaults వేరుగా పనిచేస్తాయి. అందువల్ల అవి తరచుగా గందరగోళానికి కారణమవుతాయి. sudo-rs లో env_reset ను off చేయలేరు; అది ఎల్లప్పుడూ on లో ఉంటుంది. use_pty defaultగా on లో ఉంటుంది. అందువల్ల command తన స్వంత pseudo-terminalలో నడుస్తుంది.

మీ wildcard sudoers rule ఎందుకు match కావడం ఆగిపోయింది

Wildcards ఇప్పటికీ ఒక చోట అనుమతించబడతాయి: command file name లో. %ops ALL = /sbin/fsck* నియమం ఇప్పటికీ sudo fsck మరియు sudo fsck_exfat ను అనుమతిస్తుంది. ఎందుకంటే * filesystem తో సరిపోల్చే path లో భాగంగా ఉంటుంది.

Argument list లో sudo-rs రెండు ప్రత్యేక రూపాలను మాత్రమే అంగీకరిస్తుంది. వీటిలో ఏదీ pattern కాదు. "" అంటే arguments లేవని అర్థం. చివరలో ఉన్న * అంటే చివరికి వచ్చే ఏ arguments అయినా అని అర్థం. మిగతా ప్రతి argument ను literal text గా పోల్చుతారు. అందువల్ల %ops ALL = /sbin/service ntp * సరైనది. ఇందులో ntp literal గా ఉంటుంది మరియు * చివరలో ఉంటుంది. అయితే ఈ విధమైన నియమం మీరు ఉద్దేశించిన అనుమతిని ఇవ్వదు:

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

app-* argument మధ్యలో ఉన్న pattern. sudo-rs దాన్ని expand చేయదు. అందువల్ల ఆ నియమం systemctl restart app-api ను కవర్ చేయదు మరియు sudo ఆ command ను తిరస్కరిస్తుంది. మీ స్వంత server లోని ఏ నియమం వాస్తవంగా ఏమి చేస్తుందో తెలుసుకోవడానికి రెండు commands ఉపయోగించవచ్చు: root గా అమలు చేసే sudo -l -U deploy ఆ account వాస్తవంగా ఏ commands నడపగలదో చూపిస్తుంది. sudo visudo -c ఆ file ను parse చేయడం సాధ్యమవుతుందో లేదో చెబుతుంది. యాదృచ్ఛికంగా editing ప్రారంభించే ముందు వీటిని run చేయండి.

Wildcard నియమం మొదటి నుంచే భద్రతా లోపంగా ఉంది

ప్రాథమిక sudoలో, మీరు టైప్ చేసే arguments అన్నింటినీ ఒకే stringగా కలిపి, ఆ stringను ruleలోని argument stringతో glob ద్వారా సరిపోల్చుతారు. Glob whitespaceను కూడా సరిపోల్చుతుంది. దాదాపు అందరూ గమనించకుండా వదిలేది ఇదే.

sudo-rs documentation దీనిని అత్యంత స్పష్టంగా చూపిస్తుంది. /bin/rm *.txt అనే rule, sudo rm -rf /home .txt ను కూడా అనుమతిస్తుంది. ఎందుకంటే ఒక *, -rf /home ను మొత్తం తీసుకుని, కలిపిన string చివరలో .txt తోనే ముగుస్తుంది. ఆ rule అర్థం "text files మాత్రమే". కానీ వాస్తవంగా దాని అర్థం "line చివర .txt తో ముగిస్తే ఏ arguments అయినా అనుమతించు".

systemctl ఉదాహరణకూ ఇదే వర్తిస్తుంది. Argumentsను ఒకే joined stringగా సరిపోల్చడం వల్ల, చివరలో ఉన్న pattern దాని తర్వాత మీరు జోడించే ఏదైనా విషయాన్నీ సరిపోల్చగలదు. అందువల్ల restart app-*, restart app-api తో పాటు caller జోడించే మరిన్ని argumentsనూ అనుమతిస్తుంది. ఒక argumentలోని pattern, దాని చుట్టూ ఉన్న argumentsపై నియంత్రణను వదులుతుంది. Command యొక్క అధికారం argumentsలోనే ఉంటుంది. దీన్ని సురక్షితంగా మార్చడానికి ప్రయత్నించకుండా sudo-rs ఈ నిర్మాణాన్ని తిరస్కరిస్తుంది. ఎందుకంటే దీనికి సాధారణంగా వర్తించే సురక్షిత రూపం లేదు.

Wildcard స్థానంలో స్పష్టమైన command జాబితాను ఉపయోగించండి

చాలా wildcard నియమాలు ఎవరో నాలుగు పంక్తులు టైప్ చేయకూడదనుకోవడం వల్ల ఉంటాయి. ఆ నాలుగు పంక్తులను టైప్ చేయండి.

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 ఉన్న system లో /bin/systemctl ను పేర్కొనే rule ఎప్పటికీ match కాదు. ఈ వైఫల్యం 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 లేకుండా పెట్టండి. Original sudo, dot ఉన్న పేర్లతో `sudoers.d లోని files ను విస్మరిస్తుంది. అందువల్ల 90-deploy.conf` ఒక సాధారణ silent no-op అవుతుంది. ఈ naming 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 దాని contents ను మార్చి root గా ఏదైనా అమలు చేయగలదు. ఇది మీరు తొలగించిన wildcard rule కంటే ప్రమాదకరం. ls -l తో mode ను తనిఖీ చేయండి. Output మీకు స్పష్టంగా లేకపోతే, drwxr-xr-x permission string ను చదవడం నేర్చుకోవడానికి ఐదు నిమిషాలు చాలు. ఇదే నియమం directory కి కూడా వర్తిస్తుంది: /usr/local/sbin account ద్వారా writable గా ఉండకూడదు, ఎందుకంటే writable directory ఉంటే file ను పూర్తిగా మార్చివేయవచ్చు.

ఆ పనికి ప్రత్యేక account ఇవ్వండి; sudo rule ఉపయోగించవద్దు

చాలాసార్లు అసలు ప్రశ్న ఆ command కు root అవసరం ఎందుకు అన్నదే. ప్రత్యేక user గా నడిచే service ను ఆ user తోనే నిర్వహించవచ్చు; 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 గా save చేస్తే, deploy ఎలాంటి sudo లేకుండానే systemctl restart app-api ను run చేయగలదు. దీన్ని ఉపయోగించే ఖచ్చితమైన context నుంచే test చేయండి. SSH session లో పనిచేసే rule ను cron నుండి కూడా నిర్ధారించిన తర్వాతే దానిపై ఆధారపడండి. ఏ సందర్భంలోనైనా పని చేసే account ఆ పని కోసం మాత్రమే ఉండాలి. ఇదే సూత్రం VPS పై కనీస అనుమతుల user accounts కు కూడా వర్తిస్తుంది.

sudo-rsలో లేని ఇతర అంశాలు

sudo -E అమలు కాలేదు. దానికి బదులుగా అవసరమైన variables ను 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 escapes ను నిరోధించడానికి రూపొందించిన INTERCEPT అమలు కాలేదు. నిర్ణయంతో వ్యవహరించే user ను అది ఎప్పటికీ పూర్తిగా నిరోధించలేదు. ఒక rule ద్వారా ఎవరైనా editor లేదా interpreter ను rootగా అమలు చేయగలిగితే, వారికి root ప్రాప్యత ఉన్నట్టే. ఏ sudo option కూడా దాన్ని మార్చదు.

Session recording అమలు కాలేదు. అందువల్ల I/O log లేదా sudoreplay అందుబాటులో ఉండవు. Logging syslogకు మాత్రమే వెళ్తుంది. దాన్ని మరొకచోటికి మళ్లించడానికి logfile option లేదు. కాబట్టి sudo messages మీ system ఇప్పటికే syslogను పంపే స్థానానికే వెళ్తాయి.

sudo.ws కు తిరిగి మారాలా?

మారవచ్చు. 26.04 cycle సమయంలో అసలు ప్యాకేజీని ఉంచడానికి ఇదే ప్రధాన కారణం.

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

--config output నుంచి ఖచ్చితమైన paths ను కాపీ చేయండి. ఈ పేజీ నుంచి కాపీ చేయవద్దు. మీ సిస్టమ్ అంగీకరించే జాబితా అదే. తరువాత sudo-rs కు తిరిగి మారాలంటే, అదే జాబితాలోని sudo-rs binary path కు alternative ను సెట్ చేయాలి.

sudo ను ప్రభావితం చేసే ఏ మార్పు చేయకముందు, login అయి idle గా ఉన్న రెండవ SSH session ను తెరిచి ఉంచండి. sudoers file parse కాకపోయినా, install చేయని binary కు alternative సూచించినా, remote box లో root గా మారడానికి మార్గం లేకుండా పోవచ్చు. కొత్త VPS పై మొదటి పది నిమిషాలు చేసే అన్ని పనుల్లో ఈ అలవాటును కూడా భాగంగా చేసుకోండి.

తిరిగి మారడాన్ని పరిష్కారంగా కాకుండా గడువుగా పరిగణించండి. నియమాలను సరిగ్గా తిరిగి రాయడానికి ఇది మీకు ఒక వారం సమయం ఇస్తుంది. ఆ rewrite ను స్వతంత్రంగా చేయడం కూడా విలువైనదే. ఎందుకంటే మీరు తొలగించే ప్రతి wildcard rule, దాన్ని రాసిన వ్యక్తి ఉద్దేశించిన దానికంటే ఎక్కువ అనుమతులను మంజూరు చేసి ఉండేది.

FAQ

నా sudoers wildcard నియమం Ubuntu 26.04లో ఎందుకు పనిచేయడం ఆపింది?

Ubuntu 26.04 LTSలో sudo-rs డిఫాల్ట్ sudoగా ఎంపిక అవుతుంది. sudo-rs కమాండ్ arguments లోని wildcard patterns ను సరిపోల్చదు. ఇది కమాండ్ file nameలో wildcardను, ఎటువంటి arguments లేవని సూచించే "" ను, అలాగే చివరి argumentగా ఉన్న ఒకే * ను మాత్రమే అనుమతిస్తుంది. /usr/bin/systemctl restart app-* వంటి నియమం argument మధ్యలో patternను ఉంచుతుంది. అందువల్ల అది ఎలాంటి అనుమతినీ ఇవ్వదు మరియు కమాండ్ తిరస్కరించబడుతుంది. ఆ accountకు వాస్తవంగా ఉన్న అనుమతులను rootగా sudo -l -U deploy నడిపి చూడండి. తరువాత ఆ నియమాన్ని ఖచ్చితమైన commandsతో లేదా root-owned wrapper scriptతో మార్చండి.

Ubuntu 26.04లో అసలు sudoకు తిరిగి ఎలా మారాలి?

అసలు sudo, sudo.wsగా package చేయబడింది. sudo apt install sudo.wsతో దాన్ని install చేయండి. తరువాత sudo update-alternatives --set sudo /usr/bin/sudo.wsతో alternativeను దానికి point చేయండి. ముందుగా update-alternatives --config sudo నడిపి మీ system అందించే ఖచ్చితమైన pathsను చూడండి. మార్పు చేస్తున్నప్పుడు రెండో SSH sessionను openలో ఉంచండి. మీరు ఏ implementationను ఎంచుకున్నా, ఇది sudo-ldapను తిరిగి తీసుకురాదు. అది 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ను close చేయడానికి ముందు sudo visudo -cతో verify చేయండి.

sudo-rsలో `sudo -E` స్థానంలో ఏమి ఉపయోగిస్తారు?

sudo -E implement చేయబడలేదు. అసలు sudoలో కూడా ఇది ఇప్పటికే నిరుత్సాహపరచబడింది. ఎందుకంటే caller నియంత్రించే environmentను root processకు ఇవ్వడం, ఆ process ప్రవర్తించే విధానాన్ని మార్చడానికి తెలిసిన మార్గం. మీకు నిజంగా అవసరమైన variablesను sudoersలో స్పష్టంగా పేర్కొనండి. ఉదాహరణకు Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" వంటి lineను ఉపయోగించండి. sudo-rsలో env_reset ఎల్లప్పుడూ enabledగా ఉంటుంది. దాన్ని disable చేయలేరు. అందువల్ల మీరు ఉంచని ప్రతి variable clear చేయబడుతుంది.

#sudo#sudo-rs#ubuntu#sudoers#permissions