SELinux వల్ల nginx 403: permissions సరైనవైనా ఎందుకు?

సరైన permissions ఉన్న ఫైల్‌పై nginx 403 ఎందుకు ఇస్తుంది

ఫైల్ permission bits సరైనవిగా ఉన్నప్పటికీ nginx 403 ఇవ్వడం దాదాపు ఎల్లప్పుడూ SELinux (security-enhanced Linux) read ను నిరాకరించడం వల్ల జరుగుతుంది. సాధారణ permissions తనిఖీ విజయవంతమైన తర్వాత SELinux మరో నియమాల సమూహాన్ని తనిఖీ చేస్తుంది. web server, web content label ఉన్న ఫైళ్లను మాత్రమే చదవగలదు. మీ ఫైల్‌కు వేరే label ఉండటంతో open విఫలమవుతుంది. అందువల్ల nginx పంపడానికి ఏమీ ఉండదు.

mode మాత్రమే కాకుండా label ను కూడా చూడండి:

ls -ldZ /data/www /data/www/index.html

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /data/www
-rw-r--r--. root root unconfined_u:object_r:default_t:s0 /data/www/index.html

drwxr-xr-x తర్వాత కనిపించే dot, ఫైల్‌కు SELinux label ఉందని సూచిస్తుంది. policy కి ఆ path గురించి ఇంతవరకు తెలియనప్పుడు default_t వస్తుంది. web server నియమాల్లో ఆ type ను చదవడానికి అనుమతి ఉండదు. error log సాధారణ Unix error ను చూపిస్తుంది. అందుకే ఇది permissions సమస్యలా కనిపిస్తుంది:

2026/08/11 09:14:02 [error] 1183#1183: *1 open() "/data/www/index.html" failed (13: Permission denied), client: 203.0.113.9, server: _, request: "GET / HTTP/1.1"

సాధారణ నిరాకరణకైనా, SELinux నిరాకరణకైనా kernel 13: Permission denied ను తిరిగి ఇస్తుంది. కాబట్టి ముందుగా ఏ layer నిరాకరించిందో గుర్తించాలి. setenforce 0 తో ప్రారంభించవద్దు.

మీకు అవసరమైన మోడల్‌లోని భాగం

SELinux అనేది mandatory access control, దీనిని సాధారణంగా MAC అని వ్రాస్తారు. ప్రతి process ఒక domainలో నడుస్తుంది; web server కోసం ఇది httpd_t వంటిది. ప్రతి file మరియు ప్రతి network portకు ఒక type ఉంటుంది; ఉదాహరణకు httpd_sys_content_t. Policy అనేది domain, type మరియు actionల అనుమతించబడిన కలయికల జాబితా. ఆ జాబితాలో లేనిదంతా నిరాకరించబడుతుంది. ఇది classic Unix check తర్వాత అమలవుతుంది. అందువల్ల drwxr-xr-x లోని permission bits ముందుగా accessను అనుమతించాలి. రెండు layers కూడా అనుమతించాలి.

పూర్తి contextలో colonలతో వేరు చేసిన నాలుగు fields ఉంటాయి; ఉదాహరణకు system_u:system_r:httpd_t:s0: SELinux user, role, type మరియు level. Serverపై మీరు దాదాపు ఎల్లప్పుడూ మూడవ field అయిన typeపైనే దృష్టి పెడతారు. ప్రస్తుత విలువలను చూపించే రెండు commands ఇవి:

ps -eZ | grep nginx
id -Z

nginx workers context httpd_tతో ముగుస్తుంది. మీ login shell unconfined_u:unconfined_r:unconfined_t:s0ను చూపుతుంది, ఎందుకంటే default targeted policy servicesను పరిమితం చేసి, interactive usersను సాధారణంగా పరిమితం చేయదు. ఇది తెలుసుకోవడం ముఖ్యం, ఎందుకంటే SELinux తక్కువ అనుమతులు కలిగిన users కింద servicesను నడపడాన్ని భర్తీ చేయదు. ఎవరో serviceలోకి చొరబడిన తర్వాత అది చేరగల వనరులను SELinux పరిమితం చేస్తుంది.

మూడు మోడ్‌లు, ఏ images లో SELinux ఉంటుంది

sestatus
getenforce

Enforcing నిరోధించి, log నమోదు చేస్తుంది. Permissive అన్నింటినీ అనుమతించి, అది ఏవాటిని నిరోధించేదో log నమోదు చేస్తుంది. Disabled ఎలాంటి policy ని load చేయదు. getenforce ప్రస్తుత mode ను చూపుతుంది. sestatus /etc/selinux/config నుంచి mode ను కూడా చూపుతుంది. Reboot తర్వాత తిరిగి వచ్చే mode ఇదే.

Rocky Linux, AlmaLinux, Fedora మరియు RHEL, targeted policy తో SELinux ను enforcing mode లో విడుదల చేస్తాయి. Ubuntu మరియు Debian బదులుగా AppArmor ను విడుదల చేస్తాయి. ఇది వేరే mechanism తో అదే పని చేస్తుంది. (చివరి section లో దీని గురించి వివరించబడుతుంది.) అందువల్ల ఒకే application మీ ఒక server లో సులభంగా install అయి, మరొక server లో 403 ను చూపించవచ్చు.

మీకు అవసరం కలగకముందే సాధనాలను ఇన్‌స్టాల్ చేయండి

sudo dnf install -y policycoreutils-python-utils setroubleshoot-server

కనిష్ఠ imageలో semanage: command not found ఉంటే, policycoreutils-python-utils అందుబాటులో లేదని అర్థం: ఆ packageలో semanage మరియు audit2allow ఉంటాయి. setroubleshoot-server sealert ను జోడించి, ప్రతి నిరాకరణకు సంబంధించిన సులభమైన ఆంగ్ల సారాంశాన్ని journalలో వ్రాస్తుంది. కొత్త serverలో ఈ రెండింటినీ ముందుగానే ఇన్‌స్టాల్ చేయండి. ఎందుకంటే అవి అవసరమయ్యే సమయానికి ఏదో ఒకటి ఇప్పటికే పనిచేయడం ఆపి ఉంటుంది.

audit logలో SELinux నిరాకరణను ఎలా చదవాలి

ప్రతి నిరాకరణను audit daemon AVC (access vector cache) సందేశంగా నమోదు చేస్తుంది:

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

type=AVC msg=audit(1754896442.881:412): avc:  denied  { read } for  pid=1183 comm="nginx" name="index.html" dev="vda1" ino=17203 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0

ఈ మొత్తం విషయాన్ని నాలుగు fields వివరిస్తాయి. comm నిరోధించబడిన program. scontext source context; అంటే process అమలవుతున్న domain. tcontext target context; process access చేయడానికి ప్రయత్నించిన వస్తువుపై ఉన్న label. tclass object రకం; ఇక్కడ అది file. వీటిని కలిపి చదివితే: httpd_t లోని process default_t label ఉన్న fileను చదవడానికి ప్రయత్నించింది. ఆ అభ్యర్థన కేవలం log చేయబడిందా లేదా నిజంగా నిరోధించబడిందా అన్నది permissive=0 చూపిస్తుంది.

ausearch ఏ output ఇవ్వకపోతే audit daemon అమలులో లేకపోవచ్చు. అప్పుడు నిరాకరణలు kernel ring bufferలో నమోదవుతాయి:

sudo journalctl -k | grep -i avc

ఇప్పుడు recordను ఒక English వాక్యంగా మార్చి చూడండి:

sudo ausearch -m AVC -ts recent | audit2why
sudo journalctl -t setroubleshoot --since today
sudo sealert -a /var/log/audit/audit.log

audit2why అదే recordsను చదివి, తాను గుర్తించిన కారణాన్ని పేర్కొంటుంది: offలో ఉన్న boolean, policyతో సరిపోని label, లేదా అసలు rule లేకపోవడం. sealert మొత్తం logను పరిశీలించి, ప్రతి నిరాకరణకు ఒక సూచించిన commandను చూపిస్తుంది. ఈ సూచనను hintగా మాత్రమే పరిగణించండి. Releases మధ్య wording మారుతుంది. కొన్నిసార్లు sealert custom policy moduleను సూచిస్తుంది. కానీ సరైన పరిష్కారం ఒక line label fix మాత్రమే కావచ్చు.

ఇంకో విషయం గుర్తుంచుకోండి. Policyలో harmlessగా పరిగణించిన నిరాకరణలను దాచే dontaudit rules ఉంటాయి. అందువల్ల log ఖాళీగా ఉన్నప్పటికీ program సరిగ్గా పనిచేయకపోవచ్చు. ఒక test వ్యవధికి వాటిని కనిపించేలా చేయండి:

sudo semodule -DB
# reproduce the problem, then read the log again
sudo semodule -B

semanage fcontext మరియు restorecon తో తప్పుగా ఉన్న path label ను సరిచేయడం

రెండు commands ఉన్నాయి. వాటి క్రమం ముఖ్యం. semanage fcontext -a ఒక path కు ఉండాల్సిన label ను నమోదు చేస్తుంది. restorecon ఆ నమోదైన default ను disk పై ఉన్న files కు వర్తింపజేస్తుంది.

sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
sudo restorecon -Rv /data/www
ls -ldZ /data/www/index.html

ఈ path ఒక regular expression. (/.*)? directory కి మరియు దాని కింద ఉన్న ప్రతిదానికి వర్తిస్తుంది. Document root కు ఇదే అవసరం. మార్చే ముందు ఏ మార్పులు జరుగుతాయో చూడండి: sudo restorecon -Rvn /data/www చేయబోయే relabels ను చూపిస్తుంది, ఎందుకంటే -n అంటే ఎలాంటి చర్య తీసుకోవద్దు. నిజమైన restorecon తర్వాత label httpd_sys_content_t గా కనిపిస్తుంది. Service ను restart చేయకుండానే 403 సమస్య తొలగిపోతుంది.

chcon ను పరీక్షగా మాత్రమే ఉపయోగించండి. chcon -t httpd_sys_content_t index.html label ను నేరుగా అమర్చుతుంది. తరువాతి restorecon, package update లేదా full relabel సమయంలో అది reset అవుతుంది, ఎందుకంటే ఆ path వేరే label కలిగి ఉండాలని policy ఇంకా చెబుతుంది. నిలిచిపోయే version semanage fcontext. మీరు నమోదు చేసిన వాటిని sudo semanage fcontext -l | grep '^/data' తో జాబితా చేయండి.

Service రాయాల్సిన content కు వేరే type అవసరం. Upload directory లేదా cache కోసం httpd_sys_rw_content_t ఉపయోగించండి. దాన్ని అవసరమైన paths కు మాత్రమే పరిమితం చేయండి. Writable type కింద ఉన్న read-only site application కు అవసరమైన దానికంటే ఎక్కువ access అందిస్తుంది.

అసలు label ఎందుకు తప్పుగా ఉంది? దాదాపు ఎల్లప్పుడూ files ఎలా వచ్చాయన్నదే కారణం. mv file యొక్క existing label ను అలాగే ఉంచుతుంది. అందువల్ల /root నుండి తరలించిన site admin_home_t label తో వస్తుంది మరియు అలాగే కొనసాగుతుంది. సాధారణ cp కొత్త file కు destination directory యొక్క default label ను ఇస్తుంది. సాధారణంగా ఇదే కావాలి. అయితే cp -a మరియు rsync -X source labels ను కూడా file తో పాటు copy చేస్తాయి. కొత్త top-level directory లోకి చేసిన git clone వల్ల default_t ఏర్పడుతుంది. /usr/share/nginx/html నుండి page సరిగ్గా load అయి, మీ స్వంత directory నుండి విఫలమైతే కారణం ఇదే.

బూలియన్‌తో ప్రవర్తనా సమస్యను సరిచేయండి

కొన్ని వైఫల్యాలు label సమస్య వల్ల కలగవు. కొత్త Rocky లేదా AlmaLinux సిస్టమ్‌లో reverse proxy 502 ను చూపిస్తుంది, మరియు error log ఇలా ఉంటుంది:

2026/08/11 10:02:55 [crit] 1183#1183: *3 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream

మీ upstream సరిగ్గానే ఉంది. httpd_t domain కు డిఫాల్ట్‌గా outbound network connections తెరవడానికి అనుమతి ఉండదు. అందువల్ల connect() call loopback interface కు చేరకముందే తిరస్కరించబడుతుంది. ఈ మొత్తం ప్రవర్తనను ఒకే switch నియంత్రిస్తుంది:

getsebool -a | grep httpd_can_network
sudo setsebool -P httpd_can_network_connect on

ముఖ్యమైన flag -P. ఇది విలువను disk పై రాస్తుంది. -P లేకపోతే తదుపరి reboot సమయంలో ఈ మార్పు పోతుంది. అప్పుడు machine restart అయ్యే వరకు మాత్రమే service పనిచేస్తుంది. ప్రస్తుతం అమలులో ఉన్న విలువను stored విలువ పక్కన చూపించే semanage boolean -l | grep httpd_can_network_connect తో నిర్ధారించండి.

అలాంటి అవకాశం ఉన్నప్పుడు స్వయంగా రాసిన rule కంటే boolean ను ఎంచుకోండి. Booleans distribution policy తోనే వస్తాయి. అందువల్ల వాటిని నిర్వహించడం, document చేయడం, తరువాతి వ్యక్తి కనుగొనడం సులభం. సిస్టమ్‌లోని అన్ని booleans ను getsebool -a చూపిస్తుంది.

ఒక సేవను non-standard port పై listen చేయేలా చేయండి

Ports కు labels కూడా ఉంటాయి. nginx ను 8081 కు మార్చితే, అది start కావడానికి నిరాకరిస్తుంది:

nginx: [emerg] bind() to 0.0.0.0:8081 failed (13: Permission denied)

httpd_t కేవలం http_port_t ports కు bind కావచ్చు. 8081 వాటిలో లేదు. దీన్ని జోడించండి:

sudo semanage port -l | grep -w http_port_t
sudo semanage port -a -t http_port_t -p tcp 8081

ముందుగా జాబితాను పరిశీలించండి. 8008 మరియు 8443 సహా అనేక high ports ఇప్పటికే అనుమతించబడ్డాయి. ఒకే port ను రెండుసార్లు జోడిస్తే ValueError: Port tcp/8081 already defined విఫలమవుతుంది. ఆ port ఇప్పటికే వేరే type కు చెందినదైతే, దాన్ని జోడించకుండా semanage port -m -t http_port_t -p tcp 8081 తో మార్చండి.

మార్చిన SSH port పనిచేయడానికి కూడా ఇదే command అవసరం. journalctl -u sshd లోని Bind to port 2222 on 0.0.0.0 failed: Permission denied ప్రకారం, ssh_port_t లో 2222 లేదు. అందువల్ల daemon ను restart చేసి మీ session ను మూసివేయడానికి ముందు sudo semanage port -a -t ssh_port_t -p tcp 2222 అమలు చేయండి. Red Hat family image పై VPSలో SSHను hardening చేయడం గురించి generic guide అనుసరించేటప్పుడు చాలామంది దాటవేసే దశ ఇదే. SELinux firewall కాదు. కాబట్టి port ఇంకా open అయి ఉండాలి: ఇక్కడ sudo firewall-cmd --permanent --add-port=8081/tcp && sudo firewall-cmd --reload ఉపయోగించండి, లేదా Debian లేదా Ubuntu image పై ufw ఉపయోగించండి.

Boolean లేదా మార్చాల్సిన label ఏదీ లేనప్పుడు

సాధారణ serverలో ఇది అరుదుగా జరుగుతుంది. ఇలాంటి సందర్భాల్లోనే నష్టం కలిగించే అవకాశం ఎక్కువ. Logలోని denials ఆధారంగా audit2allow ఒక policy moduleను రూపొందించగలదు:

sudo ausearch -m AVC -ts recent -c nginx | audit2allow -M nginx_local
cat nginx_local.te
sudo semodule -i nginx_local.pp

దాన్ని install చేయడానికి ముందు nginx_local.te చదవండి. ఈ ప్రక్రియను సురక్షితంగా ఉంచడానికి రెండు అలవాట్లు అవసరం. మీరు సరిచేస్తున్న ఒక్క programకు మాత్రమే inputను -c తో filter చేయండి. ఎందుకంటే సంబంధం లేని ఒక వారం denialsను audit2allow కు pipe చేస్తే, అవన్నీ ఒకేసారి అనుమతించబడతాయి. మీరు వివరించలేని denial ఆధారంగా రూపొందించిన moduleను ఎప్పుడూ install చేయవద్దు. ఉదాహరణకు, httpd_t కు systemలోని ప్రతి fileను చదవడానికి అనుమతించే ruleను సులభంగా రూపొందించవచ్చు. కానీ నెలల తర్వాత దాన్ని గుర్తించడం కష్టం. sudo semodule -r nginx_local తో moduleను తొలగించండి.

Permissive నిర్ధారణ కోసం ఉపయోగించే మోడ్; ఇది పరిష్కారం కాదు

sudo setenforce 0
# reproduce the problem once, all the way through
sudo ausearch -m AVC -ts recent
sudo setenforce 1

Permissive మోడ్ access ను అనుమతించి, దాన్ని log చేస్తుంది. దీని అసలు ప్రయోజనం సంపూర్ణత. Enforcing మోడ్‌లో service మొదటి denial వద్ద ఆగిపోతుంది. మీరు దాన్ని సరిచేసి, service ను restart చేసిన తర్వాత రెండో denial ను ఎదుర్కొంటారు. Permissive మోడ్‌లో ప్రక్రియ కొనసాగుతుంది. ఒకే runలో ప్రతి denial logలో సేకరించబడుతుంది. ఆ తర్వాత మీరు enforcing మోడ్‌కు తిరిగి మారి, వాటన్నింటినీ కలిసి సరిచేయవచ్చు.

setenforce అనేది /etc/selinux/config ను మార్చదు. అందువల్ల reboot చేసినప్పుడు system తిరిగి enforcing మోడ్‌లోకి వస్తుంది. ఇది ఒక safety net. అలాగే setenforce 0 ను అమలు చేయడమే "పరిష్కారం"గా భావించిన మార్పు అత్యంత అనుకూలం కాని సమయంలో మళ్లీ కనిపించడానికి ఇదే కారణం. మీరు ఒక service పై పని చేస్తున్నప్పుడు దానికి తాత్కాలికంగా అదనపు అనుమతి అవసరమైతే, మొత్తం machine కు కాకుండా ఆ domain ను మాత్రమే గుర్తించండి: sudo semanage permissive -a httpd_t మిగతా అన్నింటినీ enforcing మోడ్‌లోనే ఉంచుతుంది. sudo semanage permissive -d httpd_t ఆ మార్పును తిరిగి రద్దు చేస్తుంది.

SELinux label ను సరిచేయడం కంటే SELinux ను నిలిపివేయడానికి ఎక్కువ ఖర్చవుతుంది

/etc/selinux/config లో SELINUX=disabled ను సెట్ చేయడం ద్వారా ఒకే లైన్‌లో చేయగల label పరిష్కారానికి బదులుగా server ను శాశ్వతంగా బలహీనపరుస్తారు. Web application compromise అయిన రోజున ఈ తేడా స్పష్టంగా కనిపిస్తుంది. Enforcing మోడ్‌లో attacker code httpd_t లో నడుస్తుంది. అందువల్ల అది web content ను చదవవచ్చు. అయితే Unix user కు అనుమతి ఉన్నా, policy కారణంగా /etc/shadow చదవడం లేదా systemd unit రాయడం నిరాకరించబడుతుంది. Policy ఏదీ load చేయకపోతే, అదే code కు service account కు ఉన్న అన్ని అనుమతులు లభిస్తాయి.

SELinux ను నిలిపివేయడం వల్ల తర్వాత చెల్లించాల్సిన సమస్య కూడా ఏర్పడుతుంది. Policy ఏదీ load కాకపోయినప్పుడు కొత్త files ఎలాంటి label లేకుండా సృష్టించబడతాయి. దాంతో filesystem policy కి అనుగుణంగా ఉండదు. SELinux ను మళ్లీ enable చేసినప్పుడు పూర్తి relabel అవసరం అవుతుంది. లేకపోతే అనేక services ఒకేసారి fail కావచ్చు:

sudo fixfiles -F onboot
sudo reboot

ఇది /.autorelabel ను రాస్తుంది. తరువాతి boot సమయంలో ప్రతి filesystem కు relabel చేస్తుంది. పెద్ద disk పై దీనికి ఎక్కువ సమయం పడుతుంది. Console స్పందించనట్లు కనిపించవచ్చు. అందువల్ల వేచి ఉండగల సమయంలో దీన్ని ప్రారంభించండి. Rocky Linux మరియు AlmaLinux 9 లో config file kernel భాగాన్ని స్వయంగా నిలిపివేయదు. SELinux ను పూర్తిగా disable చేయడానికి documented విధానం kernel argument (sudo grubby --update-kernel ALL --args selinux=0) ఉపయోగించడం. ఇతరులు నిర్వహించిన server ను మీరు స్వీకరించినప్పుడు ఆ command తెలుసుకోవడం ఉపయోగకరం. 403 error కు ఇది పరిష్కారం కాదు.

Containers కు మరో label అవసరం

Red Hat కుటుంబానికి చెందిన hostలో container processes container_t లో నడుస్తాయి. అవి container_file_t label ఉన్న files ను మాత్రమే చదవగలవు. Host నుంచి చేసిన bind mount, container లో Permission denied కారణంగా విఫలమవుతుంది. అయితే hostలో ls -l సరిగ్గా కనిపిస్తుంది. :Z suffix ద్వారా runtime mountకు మళ్లీ label వర్తింపజేయాలని సూచించవచ్చు:

docker run -d -v /data/appdata:/var/lib/app:Z myimage

:Z ఆ directoryకి ఈ container కోసం మాత్రమే label వర్తింపజేస్తుంది. :z దాన్ని containers మధ్య share చేయడానికి label చేస్తుంది. ఇతర services ఉపయోగించే directory వైపు :Z ను చూపిస్తే, అది ఆ directory మొత్తానికి recursiveగా relabel చేస్తుంది. దీంతో ఆ services పనిచేయడం ఆగిపోవచ్చు. అందువల్ల containers కోసం ప్రత్యేక paths ఉపయోగించండి. మిగతా setup ఏ ఇతర image setup మాదిరిగానే ఉంటుంది. దీనిని VPSపై Docker నడపడం లో వివరించారు.

Ubuntu మరియు Debian మీకు AppArmor అందిస్తాయి

పని ఒకటే, రూపకల్పన వేరు. AppArmor, డిస్క్‌లోని ఫైళ్లకు labelలు కేటాయించడం బదులుగా, /etc/apparmor.d/ లోని profileను ఉపయోగించి executable path ఆధారంగా ప్రోగ్రామ్‌ను పరిమితం చేస్తుంది. Relabel చేయాల్సినది ఏదీ ఉండదు; restorecon కూడా అవసరం లేదు. ఇక్కడి నుంచి ప్రారంభించండి:

sudo aa-status
sudo journalctl -k | grep -i apparmor

నిరాకరణ apparmor="DENIED" operation="open" profile="/usr/sbin/nginx" name="/data/www/index.html" requested_mask="r" గా కనిపిస్తుంది. విధానం కూడా అదే: denialను చదవండి, profileను కనుగొనండి, ruleను మార్చండి. sudo apt install apparmor-utils ద్వారా aa-complain (ఒక profileకు permissive mode) అమలు చేయవచ్చు; దాన్ని మళ్లీ సాధారణ స్థితికి తీసుకురావడానికి aa-enforce ఉపయోగించండి. Ubuntu ప్యాకేజీగా వచ్చిన ఎంపిక చేసిన సేవలను మాత్రమే పరిమితం చేస్తుంది; మిగిలినవి unconfinedగా ఉంటాయి. కాబట్టి ఊహించకుండా, వాస్తవంగా ఏవి activeగా ఉన్నాయో తెలుసుకోవడానికి aa-status చదవండి.

రెండు వ్యవస్థలలోనూ ఒకే అలవాటు ఉపయోగపడుతుంది. సరైనదిగా కనిపించే ఏదైనా అంశంపై సేవ Permission denied అని చూపిస్తే, permissions మార్చే ముందు security log చదవండి. సాధారణంగా permissions సమస్య రెండుసార్లు కారణం కావు.

FAQ

ఫైల్ permissions సరిగ్గా ఉన్నా nginx 403 ఎందుకు చూపిస్తుంది?

SELinux read చర్యను నిరాకరించింది; permission bits కారణం కాదు. Web server httpd_t domain లో నడుస్తుంది. అందువల్ల web content కోసం label చేసిన files ను మాత్రమే చదవగలదు. default_t లేదా admin_home_t label ఉన్న file ను అది నిరాకరిస్తుంది. దాంతో nginx కు అందించడానికి file ఉండదు. దీన్ని sudo ausearch -m AVC -ts recent తో నిర్ధారించండి. ఇది scontext, httpd_t తో ముగిసే entry, అలాగే తప్పు type కలిగిన tcontext ను చూపిస్తుంది. తరువాత సరైన label ను నమోదు చేసి వర్తింపజేయండి: sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?", ఆపై sudo restorecon -Rv /data/www.

సేవను పనిచేయించడానికి setenforce 0 నడపడం సురక్షితమేనా?

setenforce 0 ఒక diagnostic step మాత్రమే; అది పరిష్కారం కాదు. సమస్యను ఒకసారి పునరుత్పత్తి చేయడానికి దీన్ని ఉపయోగించండి. అప్పుడు log ఒకే pass లో అన్ని denials ను నమోదు చేస్తుంది. వాటిని sudo ausearch -m AVC -ts recent తో చదవండి. తరువాత sudo setenforce 1 నడిపి కారణాలను సరిచేయండి. permissive mode లో server ఉంచితే ప్రతి denial log అవుతుంది, కానీ ఏదీ నిరోధించబడదు. అందువల్ల log noise కొనసాగుతుంది, protection మాత్రం ఉండదు. మీరు పని చేస్తున్న సమయంలో ఒక service కు తాత్కాలికంగా సడలింపు అవసరమైతే sudo semanage permissive -a httpd_t నడపండి. అప్పుడు మిగిలిన machine enforcing mode లోనే ఉంటుంది.

SELinux enforcing mode లో non-standard port పై service ను ఎలా నడపాలి?

ఆ service bind చేయడానికి అనుమతించబడిన type కు port ను జోడించండి. 8081 పై web server కోసం: sudo semanage port -a -t http_port_t -p tcp 8081. 2222 పై SSH కోసం: sudo semanage port -a -t ssh_port_t -p tcp 2222. ముందుగా ప్రస్తుత list ను sudo semanage port -l | grep -w http_port_t తో తనిఖీ చేయండి. ఎందుకంటే ఇప్పటికే list లో ఉన్న port తో ValueError: Port tcp/8081 already defined విఫలమవుతుంది. ఈ దశ లేకపోతే, మరే ఇతర process ఆ port ను ఉపయోగించకపోయినా daemon startup సమయంలో bind() ... Permission denied తో ముగుస్తుంది.

Ubuntu లో SELinux ఉందా?

లేదు. Ubuntu మరియు Debian AppArmor ను అందిస్తాయి. ఇది files పై labels ఆధారంగా కాకుండా executable path కు అనుసంధానమైన profile ఆధారంగా enforcement చేస్తుంది. దీన్ని sudo aa-status తో తనిఖీ చేయండి. sudo journalctl -k లో apparmor="DENIED" lines కోసం చూడండి. Ubuntu కొన్ని packaged services ను మాత్రమే confine చేస్తుంది. అందువల్ల అనేక programs default గా unconfined గా నడుస్తాయి. Rocky Linux మరియు AlmaLinux లో, అలాగే Fedora మరియు RHEL లో, SELinux enforcing mode default గా ఉంటుంది.