OpenVPN ಹುಕ್ ತನ್ನ ಸ್ಕ್ರಿಪ್ಟ್ನ ಪಕ್ಕದ ಫೈಲ್ ಏಕೆ ಹುಡುಕಲಾರದು

ದೋಷವಿಲ್ಲದೆ ಚಲಿಸಿ ಆದರೂ ಕಾಣೆಯಾದ ಫೈಲ್ ಅನ್ನು ವರದಿ ಮಾಡುವ ಹುಕ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಸ್ಥಳವನ್ನು ನೋಡುತ್ತವೆ, ತಮ್ಮ ಕೆಲಸದಲ್ಲಿ ವಿಫಲವಾಗುವುದಿಲ್ಲ. ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿನ ಸಾಪೇಕ್ಷ ಮಾರ್ಗಗಳು ಪ್ರಕ್ರಿಯೆಯ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿಗೆ ಸಂಬಂಧಿಸಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ, ಮತ್ತು ಸೇವೆಯು ನೀವು ಆಯ್ಕೆ ಮಾಡದ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್ನ ಪಕ್ಕದ ಫೈಲ್ ಮತ್ತು ಪ್ರಕ್ರಿಯೆ ತೆರೆಯುವ ಫೈಲ್ ಒಂದೇ ವಿಷಯವಾಗುವುದು ಯಾವುದೋ ಅವನ್ನು ಆಂಕರ್ ಮಾಡಿದಾಗ ಮಾತ್ರ. ಆ ವ್ಯತ್ಯಾಸವೇ ಅನುಮತಿ ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಓದಲ್ಪಡುವ ಹುಕ್ ವೈಫಲ್ಯಗಳ ದೊಡ್ಡ ಭಾಗವನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಅನುಮತಿಗಳ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪು ಫೈಲ್ನ ಮೇಲಿನ ಅನುಮತಿ ದೋಷವು ಇನ್ನೂ ತಪ್ಪು ಫೈಲ್.

ಸಾಪೇಕ್ಷ ಮಾರ್ಗವು ಫೈಲ್ಗೆ ಅಲ್ಲ, ಪ್ರಕ್ರಿಯೆಗೆ ಸಂಬಂಧಿಸಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ

ಸ್ಕ್ರಿಪ್ಟ್ open("policy.json") ಅನ್ನು ಕರೆದಾಗ, ಕರ್ಣಲ್ ಹೆಸರನ್ನು ಪ್ರಕ್ರಿಯೆಯ ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿಗೆ ಸಂಬಂಧಿಸಿ ಪರಿಹರಿಸುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್ನ ಸ್ವಂತ ಸ್ಥಳದಿಂದ ಯಾವುದೂ ಆ ಹುಡುಕಾಟದಲ್ಲಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ. OpenVPN ತಾನೇ ಆಯ್ಕೆ ಮಾಡಿದ ಡೈರೆಕ್ಟರಿಯಿಂದ ಹುಕ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮತ್ತು cd ಆಯ್ಕೆಯು ಅದನ್ನು ಬದಲಿಸಬಹುದು, ಆದ್ದರಿಂದ ತನ್ನದೇ ಫೋಲ್ಡರ್ನಿಂದ ಕೈಯಿಂದ ಪರೀಕ್ಷಿಸಿದ ಸ್ಕ್ರಿಪ್ಟ್ ಡೀಮನ್ ಅದನ್ನು ಚಲಾಯಿಸಿದಾಗ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ. ಕೈ ಪರೀಕ್ಷೆ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ, ಸೇವೆ ಚಲಾಯಿಸುವುದು ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಲಾಗ್ ಸಾಲು ಕಾಣೆಯಾದ ಹೆಸರನ್ನು ಮಾತ್ರ ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

Python ಸ್ಕ್ರಿಪ್ಟ್ನ ಸ್ಥಳವನ್ನು __file__ ಆಗಿ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಆಂಕರಿಂಗ್ ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. Path(__file__).resolve().parent / "policy.json" ಪ್ರಕ್ರಿಯೆಯಿಂದ ಅಲ್ಲ, ಫೈಲ್ನಿಂದ ಮಾರ್ಗವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ಆ ಒಂದು ಸಾಲು ಸವಲತ್ತುಗಳಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸದೆ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿ ಅವಲಂಬನೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಮಾರ್ಗವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಂಕರ್ ಮಾಡಿ, ನಂತರ resolve ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

resolve() ಸಾಂಕೇತಿಕ ಕೊಂಡಿಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹುಕ್ ಅನ್ನು ಅದರ ಸ್ಥಳಕ್ಕೆ ಜೋಡಿಸುವ ಸ್ಥಾಪನೆ ಕೊಂಡಿಯ ಗುರಿಯಲ್ಲಿ ಆಂಕರ್ ಆಗುತ್ತದೆ, ಕೊಂಡಿಯನ್ನು ಹಿಡಿದಿರುವ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಅಲ್ಲ. ಸಂಸ್ಕರಣೆಯುಳ್ಳ ನಿಯೋಜನೆಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದೇ ಬೇಕಾದುದು, ಮತ್ತು ಸಾಂಕೇತಿಕ ಕೊಂಡಿಯ ಪಕ್ಕದಲ್ಲಿ ಡೇಟಾವನ್ನು ನಿರೀಕ್ಷಿಸುವ ವಿನ್ಯಾಸಕ್ಕೆ ಇದು ತಪ್ಪು. ನಿಯೋಜನೆ ಯಾವುದನ್ನು ಅರ್ಥೈಸುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ವ್ಯತ್ಯಾಸವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಬದಲು ಅದಕ್ಕೆ ತಕ್ಕಂತೆ ಕೋಡ್ ಬರೆಯಿರಿ. Path(__file__).parent ಇಲ್ಲದೆ resolve() ಕೊಂಡಿಯ ಸ್ವಂತ ಡೈರೆಕ್ಟರಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.

ಡೇಟಾ ಪ್ರೋಗ್ರಾಂಗೆ ಅಲ್ಲ, ಇನ್ಸ್ಟಾನ್ಸ್ಗೆ ಸೇರಿದ್ದರೆ, ಸಂರಚನೆಯಿಂದ ಸಂಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ಸ್ಥಳವನ್ನು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡುವುದು ಹುಕ್ ಅನ್ನು ಒಂದು ಹೋಸ್ಟ್ ವಿನ್ಯಾಸಕ್ಕೆ ಬಂಧಿಸುತ್ತದೆ.

ನಾಲ್ಕು ಗಡಿಗಳನ್ನು ಕ್ರಮವಾಗಿ ದಾಟಿ

ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ: ಯುನಿಟ್ನ WorkingDirectory, OpenVPN ನ cd ಆಯ್ಕೆ ಮತ್ತು exec ಮೊದಲು ಡೈರೆಕ್ಟರಿ ಬದಲಿಸುವ ಯಾವುದೇ ಆವರಣವನ್ನು ಹೋಲಿಸಿ. ನಂತರ ಪರಿಹರಿಸಿದ ಸ್ಥಳವನ್ನು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಇನ್ನೊಂದು ನಿಯೋಜನೆಯಲ್ಲಿ ಸಮಾನ ಹೆಸರಿನ ಫೈಲ್ ಹುಡುಕಾಟಕ್ಕೆ ಉತ್ತರಿಸಿ ದೋಷವನ್ನು ಮರೆಮಾಡಬಹುದು. ಮುಂದೆ ಫೈಲ್ ಸಿಸ್ಟಮ್ ನೋಟ ಬರುತ್ತದೆ: chroot ಅಥವಾ ಸೇವೆಯ mount ನೇಮ್ಸ್ಪೇಸ್ ಹೋಸ್ಟ್ನ ಸಂಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಸರಳವಾಗಿ ಅನುಪಸ್ಥಿತಗೊಳಿಸಬಹುದು. ಕೊನೆಯದು ಪ್ರವೇಶ ಗುರುತು, ಇದು ಗೋಚರತೆಯಿಂದ ಬೇರೆಯಾದ ಪ್ರಶ್ನೆ.

ProtectHome ಮತ್ತು PrivateTmp ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳನ್ನು ಮರೆಮಾಡುತ್ತವೆ, ಮತ್ತು ಹೋಸ್ಟ್ನಿಂದ ತೆಗೆದ ಡೈರೆಕ್ಟರಿ ಪಟ್ಟಿಯಲ್ಲಿ ಯಾವುದೂ ಕಾಣುವುದಿಲ್ಲ. ಶೆಲ್ನಲ್ಲಿ root ಗೆ ಇರುವ ಮಾರ್ಗವು ಯುನಿಟ್ನ ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗೆ ಅಗೋಚರವಾಗಿರಬಹುದು, ಆದ್ದರಿಂದ ಸೇವೆಯ ಹೊರಗೆ ಅದೇ ಆದೇಶವನ್ನು ಪರೀಕ್ಷಿಸುವುದು ತೀರಾ ಕಡಿಮೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಸೇವೆಯನ್ನು ವಿಸ್ತರಿಸದೆ ಹುಡುಕಾಟವನ್ನು ಸರಿಪಡಿಸಿ

ಮಾರ್ಗವನ್ನು ಆಂಕರ್ ಮಾಡುವುದು ಮೊದಲ ಗಡಿಯನ್ನು ಮಾತ್ರ ಪರಿಹರಿಸುತ್ತದೆ. ಅದು ಸೇವೆ ಮರೆಮಾಡುವ ಡೈರೆಕ್ಟರಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸವಲತ್ತಿಲ್ಲದ ಖಾತೆಗೆ root ಗೆ ಮಾತ್ರ ಎಂಬ ಫೈಲ್ಗೆ ಪ್ರವೇಶ ನೀಡುವುದಿಲ್ಲ. script-security ಹೆಚ್ಚಿಸುವುದು OpenVPN ಯಾವ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ; ಸಾಪೇಕ್ಷ ಹೆಸರು ಎಲ್ಲಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಅದರ ಯಾವುದೇ ಪರಿಣಾಮವಿಲ್ಲ. ಇಡೀ ಸೇವೆಗೆ ಕಾರ್ಯನಿರ್ವಹಣಾ ಡೈರೆಕ್ಟರಿ ಬದಲಿಸುವುದು ಸಮಸ್ಯೆಗಿಂತ ವಿಶಾಲವಾದದ್ದು, ಏಕೆಂದರೆ ಪ್ರತಿ ಇತರ ಸಾಪೇಕ್ಷ ಪ್ರಮಾಣಪತ್ರ, ಲಾಗ್ ಅಥವಾ ಸಹಾಯಕ ಮಾರ್ಗವು ಅದರೊಂದಿಗೆ ಚಲಿಸುತ್ತದೆ.

ಸಣ್ಣ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ: ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ನಿರ್ಣಾಯಕ ಮಾರ್ಗ, ಇನ್ಸ್ಟಾನ್ಸ್ ಡೇಟಾಗೆ ಸ್ಪಷ್ಟ ಸಂರಚನಾ ಮೌಲ್ಯ, ಮತ್ತು ಹುಕ್ ನಿಜವಾಗಿ ಚಲಿಸುವ ಖಾತೆಗೆ ಹೊಂದುವ ಫೈಲ್ ಮಾಲೀಕತ್ವ.

ಗಡಿಯನ್ನು ಹೆಸರಿಸುವ ಸಾಕ್ಷ್ಯವನ್ನು ದಾಖಲಿಸಿ

ಉಪಯುಕ್ತ ವೈಫಲ್ಯ ವರದಿಯಲ್ಲಿ ಮೂರು ವಿಷಯಗಳಿರುತ್ತವೆ: ಹುಕ್ ಪ್ರಯತ್ನಿಸಿದ ನಿಖರ ಮಾರ್ಗ, ಅದನ್ನು ಸೃಷ್ಟಿಸಿದ ಪರಿಸರ, ಮತ್ತು ಯಾವ ಗಡಿ ನಿರಾಕರಿಸಿತು. ಫೈಲ್ನ ವಿಷಯವನ್ನು ಸುರಿಯದೆ ಪರಿಹರಿಸಿದ ಮಾರ್ಗ ಮತ್ತು ವಿನಾಯಿತಿಯನ್ನು ಮುದ್ರಿಸಿ. ಆ ತ್ರಿವಳಿ ತಪ್ಪು ಆಂಕರ್ ಅನ್ನು ಮರೆಯಾದ mount ನಿಂದ ಮತ್ತು ಅನುಮತಿ ನಿರಾಕರಣೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಮತ್ತು ಅವು ಮೂರು ಬೇರೆ ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆಗಳು.

root ಟರ್ಮಿನಲ್ನಿಂದ ಫೈಲ್ ಓದಬಲ್ಲದು ಎಂಬ ಪ್ರತಿಪಾದನೆ ಆ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ, ಉಳಿದ ಯಾವುದಕ್ಕೂ ಅಲ್ಲ. ಬದಲಿಗೆ ಸೇವೆಯ ಸ್ವಂತ ಸಂದರ್ಭದಿಂದ ಪರೀಕ್ಷಿಸಿ.