લોગ ઉમેરાય છે પણ ફરી બની શકતો નથી: ડિરેક્ટરીનું ACL તપાસો
ફાઇલમાં ઉમેરવા માટે તેની ડિરેક્ટરીમાં નવું નામ જરૂરી નથી; બનાવવા માટે જરૂરી છે. કંઈપણ પહોળું કરતા પહેલાં એક્સેસ ACLની વારસાગત ડિફોલ્ટ સાથે સરખામણી કરો.
વધતો રહેતો લોગ જે ક્ષણે કંઈક તેને ફરીથી બનાવે છે તે ક્ષણે વધવાનું બંધ કરે છે, અને ભૂલ કહે છે પરવાનગી નકારી. લાલચુ નિષ્કર્ષ એ છે કે ફાઇલને પોતાને વધુ પરવાનગીઓની જરૂર છે, જ્યારે તે જ ખાતું કદાચ પહેલેથી ફાઇલમાં લખી શકે છે. હાલના નામમાં ઉમેરવું અને નવું બનાવવું જુદી જુદી તપાસ છે, અને ફક્ત બીજી જ ડિરેક્ટરીને પૂછે છે.
ઉમેરવું અને બનાવવું જુદી જુદી તપાસ છે
ઉમેરવા માટે હાલની ફાઇલ ખોલવા માટે તે ફાઇલ પર લેખન પરવાનગી અને તેના માર્ગની દરેક ડિરેક્ટરીમાં શોધ પરવાનગી જરૂરી છે. ફાઇલ બનાવવા માટે તેને સમાવતી ડિરેક્ટરી પર લેખન અને શોધ પરવાનગી જરૂરી છે, કારણ કે ક્રિયા તેમાં નામ ઉમેરે છે. નામ બદલીને ફાઇલ બદલવી બંને ડિરેક્ટરીઓ અને તેમના sticky bit નિયમોને સ્પર્શે છે.
| Operation | What must permit it | Typical failure message |
|---|---|---|
| Append to an existing log | File write access, path traversal | Permission denied on the file |
| Create a missing log | Directory write and search access | Permission denied on the path |
| Rename a replacement into place | Both directories, plus sticky restrictions | Permission denied or operation not permitted |
પહેલેથી ખુલ્લું ડિસ્ક્રિપ્ટર ચોથો કિસ્સો ઉમેરે છે. પ્રક્રિયા પોતાના વિશેષાધિકારો છોડતા પહેલાં ખોલેલું લેખનયોગ્ય હેન્ડલ રાખી શકે છે અને તેમ છતાં તેની પછીની ઓળખ સાથે એ જ માર્ગ ફરી ખોલવામાં નિષ્ફળ જાય છે. સફળ ઉમેરા અને નિષ્ફળ બનાવટ એક જ પ્રક્રિયા માટે એક જ સમયે બંને સાચા હોઈ શકે છે.
ડિફોલ્ટ ACL વારસામાં મળે છે, તે આપતા નથી
ડિફોલ્ટ પ્રીફિક્સથી શરૂ થતી એન્ટ્રી વર્ણવે છે કે નવી વસ્તુઓ ડિરેક્ટરીમાંથી શું વારસામાં લે છે. તે ડિરેક્ટરીને પોતાને કંઈ આપતી નથી અને પહેલેથી હાલની ફાઇલનું ACL સુધારતી નથી.
namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.log
એક્સેસ એન્ટ્રીઓને ડિફોલ્ટ એન્ટ્રીઓથી અલગ વાંચો, અને માસ્ક પણ વાંચો. પૂરા અધિકારો દર્શાવતી નામવાળી એન્ટ્રી પણ માસ્ક દ્વારા મર્યાદિત હોઈ શકે છે, તેથી પ્રભાવી ટિપ્પણી પ્રથમ લીટીના અક્ષરો કરતાં વધુ મહત્ત્વની છે.
રૂપરેખાંકનમાંના માર્ગને બદલે ઉકેલાયેલો માર્ગ વાપરો. સિમ્બોલિક લિંક, માઉન્ટ પોઇન્ટ કે ફરતી ડિરેક્ટરી વાસ્તવિક ફાઇલને એવી જગ્યાએ મૂકી શકે છે જ્યાં તમે આપેલી પરવાનગી ક્યારેય પહોંચતી નથી. પહેલાં namei સાથે માર્ગ ચાલો, પછી દરેક સ્તરને સંબંધિત ખાતા સાથે સરખાવો. ટોચની ડિરેક્ટરીનો અંદાજ લગાવવો એ જ રીતે સુધારો એક સ્તર વધુ ઊંચે ઉતરે છે.
એ ક્ષણે કોણ લખે છે તે ઓળખો
કંઈપણ બદલતા પહેલાં સેવા એકમ, તેના drop-in અને ડિમનની પોતાની ખાતા સેટિંગ્સ તપાસો. ઉમેરતી પ્રક્રિયા અને ફરી બનાવતી પ્રક્રિયા જુદી હોઈ શકે છે: રોટેશન સહાયક, સ્થિતિ લેખક અને વેબ વાચક ભાગ્યે જ ઓળખ વહેંચે છે.
રૂટ શેલમાંથી કરેલી પરીક્ષણ કામગીરી પ્રતિબંધિત સેવાનું પુનરુત્પાદન કરતી નથી, અને સેવા નિષ્ફળ થતી રહે ત્યારે તે સફળ થશે. નિષ્ફળ થતી ક્રિયાને એ જ એકમ હેઠળ, એ જ ખાતા અને એ જ sandbox સેટિંગ્સ સાથે પુનરુત્પાદિત કરો. જો ન કરી શકો, તો એકમને કામચલાઉ શેલ સાથે શરૂ કરો અને તે જે ઓળખ જણાવે છે તે તપાસો. બીજું કંઈપણ તમારા ટર્મિનલને માપે છે, સેવાને નહીં.
જો ખરેખર બનાવવું જરૂરી હોય, તો લેખકને સમર્પિત લોગ ડિરેક્ટરીની એક્સેસ આપો અને ઉપભોક્તાઓ માટે વાંચન એક્સેસ અલગ રાખો. એક લોગ કૉલ સંતોષવા માટે વહેંચાયેલું ખાતું કે આખું એપ્લિકેશન વૃક્ષ લેખનયોગ્ય બનાવવું નાની સમસ્યાને મોટી સાથે બદલે છે.
ભૂલ ફરી દાખલ કર્યા વિના રોટેટ કરો
જે ફાઇલ ફરી બનાવે છે તે આગલા ચક્ર માટે તેનો માલિક અને મોડ નક્કી કરે છે, તેથી સુધારાને રોટેશન રૂપરેખાંકન સાથે સંકલિત કરો. બીજા ખાતા હેઠળ કે નવા ACL સાથે બનેલો બદલો સફળ સુધારા પછી ભૂલ પાછી લાવે છે.
મોડ અને જૂથ બનાવતી વખતે સેટ કરો, પછી નહીં, અને આગલા ઉમેરાને બદલે આગલા રોટેશનને ચકાસો. ઉમેરો ફક્ત પહેલેથી પસાર થયેલી કસોટીનું પુનરાવર્તન કરે છે. જો રોટેશન સાધન બનાવટ-મોડ સેટિંગ આપે છે, તો પછીના chmodને બદલે તેનો ઉપયોગ કરો. બનાવટ અને chmod વચ્ચેનું અંતર એ જ સમય છે જ્યારે આગલું લેખન નિષ્ફળ થઈ શકે છે.
જ્યારે ટ્રંકેશન તેમ છતાં નિષ્ફળ જાય, ત્યારે પરવાનગીઓ ઉમેરવાનું બંધ કરો
તમે લખી શકો એવી ફાઇલનું ટ્રંકેશન નિષ્ફળ જવું ડિરેક્ટરી પરવાનગીઓથી સમજાતું નથી, અને તેમાંથી વધુ ઉમેરવાથી મદદ નહીં મળે. તેના બદલે લક્ષણો અને પ્રતિબંધ જુઓ: append-only લક્ષણ ફક્ત ઉમેર-મોડમાં લેખનની મંજૂરી આપે છે, અને માત્ર-વાંચન માઉન્ટ કે સેવા sandbox એ ACL મંજૂર કરતી ક્રિયા નકારી શકે છે.
એકમના ફાઇલસિસ્ટમ પ્રતિબંધો અને માર્ગ માટેના માઉન્ટ વિકલ્પો તપાસો, પછી નિષ્ફળ ગયેલી ચોક્કસ ક્રિયા પુનરુત્પાદિત કરો. જે પરવાનગી ક્યારેય પૂછાઈ જ નહીં તેને પહોળી કરવી ફક્ત એ છુપાવે છે કે કયો પ્રતિબંધ વાસ્તવિક હતો. ફેંકી દેવાય એવા એકમમાં એક સમયે એક પ્રતિબંધ દૂર કરો, અને કંઈપણ કાયમી બદલતા પહેલાં તેને પાછો મૂકો.