SELinux હેઠળ Squid ના ઇનકારનું નિદાન

Squid દ્વારા ઉત્પન્ન થયેલ HTTP ઍક્સેસ ઇનકાર અને ઓપરેટિંગ સિસ્ટમનું “Permission denied” જુદી જુદી સીમાઓ પર થાય છે. નક્કી કરો કે Squid ફાઇલ ખોલી રહ્યું હતું, સોકેટ બાંધી રહ્યું હતું, બહાર જોડાઈ રહ્યું હતું કે ક્લાયન્ટ વિનંતી નકારી રહ્યું હતું.

ઓડિટ ઘટનાને સહસંબંધિત કરો

SELinux સિસ્ટમો પર, સેવાની ભૂલને તેના ઓડિટ રેકોર્ડ સાથે મેળવો. સ્રોત ડોમેન, લક્ષ્ય પ્રકાર, ઑબ્જેક્ટ વર્ગ અને નકારેલી પરવાનગી દર્શાવે છે કે નીતિએ કઈ ક્રિયા અવરોધિત કરી. યોગ્ય Unix માલિકી સાબિત કરતી નથી કે સુરક્ષા લેબલ યોગ્ય છે.

કસ્ટમ સાંભળવાના પોર્ટને અનુરૂપ પોર્ટ લેબલની જરૂર પડી શકે છે. સ્થાનાંતરિત લોગ અથવા કેશ ડિરેક્ટરીને ફાઇલ લેબલિંગની જરૂર પડી શકે છે. Squid લોગ-પાથ નિષ્ફળતા માટે, લેબલને આરોપી ઠેરવતા પહેલાં ડિરેક્ટરી ટ્રાવર્સલ અને લેખક પરવાનગીઓ પણ તપાસો. અસામાન્ય બહાર જતી સેવા માટેની પરવાનગી ફરી બીજી ક્રિયા છે; Red Hat ના Squid SELinux ઉદાહરણો આ કેસોને અલગ કરે છે.

સ્થાપિત ડિસ્ટ્રિબ્યુશનની નીતિ અને વ્યવસ્થાપન માર્ગદર્શન વાપરો. પેકેજ પાથ, લેબલ અને મર્યાદા ઇમેજો વચ્ચે બદલાઈ શકે છે. AppArmor વાપરતી સિસ્ટમો પર, SELinux આદેશો લાગુ કરવાને બદલે તેની પ્રોફાઇલ તપાસો.

પુરાવા જે નીતિ કે સ્થાન સૂચવે છે તે સુધારો, જ્યારે હોસ્ટ અમલ જાળવી રાખો. હોસ્ટ નીતિની સમસ્યા સુધારાયા પછી પણ Squid ની પોતાની ક્લાયન્ટ પ્રમાણીકરણ અને ઍક્સેસ નિયમો લાગુ રહે છે.