OpenVPN ನಲ್ಲಿ chroot ವಿಫಲ: AppArmor ನಿಯಮ ಅಥವಾ ಸಾಮರ್ಥ್ಯ?

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

ಎರಡು ಪ್ರತ್ಯೇಕ ದ್ವಾರಗಳು, ಮತ್ತು ಒಂದೇ AppArmor‌ನದು

chroot ಪ್ರಕ್ರಿಯೆ ನಡೆಯುತ್ತಿರುವ ಬಳಕೆದಾರ ಹೆಸರಿನ ಸ್ಥಳದಲ್ಲಿ CAP_SYS_CHROOT ಅಗತ್ಯವಿದೆ. ಇದು ಸಾಮಾನ್ಯ Linux ವಿಶೇಷಾಧಿಕಾರ, ಕರೆ ಪಥಗಳೊಂದಿಗೆ ಏನನ್ನೂ ಮಾಡುವ ಮೊದಲು ಕರ್ನಲ್ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಪ್ರತ್ಯೇಕವಾಗಿ, ಜಾರಿಗೊಳಿಸುವ AppArmor ಪ್ರೊಫೈಲ್ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸಾಮರ್ಥ್ಯ ಇದ್ದರೂ ಅದನ್ನು ನಿರಾಕರಿಸಬಹುದು, ಏಕೆಂದರೆ ಕಡ್ಡಾಯ ನೀತಿಯನ್ನು ರುಜುವಾತುಗಳ ಬದಲಿಗೆ ಅವುಗಳ ಜೊತೆಗೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸ ಆಚರಣೆಯಲ್ಲಿ ಮುಖ್ಯ: ಎರಡು ಪದರಗಳು ಬೇರೆ ಬೇರೆ ಫೈಲ್‌ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಬೇರೆ ಜನರು ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತಾರೆ.

ಆ ಎರಡು ದ್ವಾರಗಳು ಒಂದೇ errno ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತವೆ. ಎರಡೂ EPERM ಉತ್ಪಾದಿಸುತ್ತವೆ, ಮತ್ತು ಎರಡೂ ಡೀಮನ್ ಲಾಗ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಅನುಮತಿ ದೂರಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್‌ನ ಒಳಗಿನದನ್ನು ಊಹಿಸುವುದು ಇಷ್ಟು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ನೀವು ಸೇರಿಸಲಿದ್ದ ಪಥದ ನಿಯಮ chroot ಯಶಸ್ವಿಯಾದ ನಂತರ ಫೈಲ್ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ; ಕಾರ್ಯಾಚರಣೆಗೆ ಅನುಮತಿ ಇದೆಯೇ ಎಂಬುದಕ್ಕೂ ಅದಕ್ಕೂ ಸಂಬಂಧವಿಲ್ಲ.

ಮೂರನೇ ದ್ವಾರ ಎರಡರ ಮೇಲಿದೆ. ಸೇವಾ ನಿರ್ವಾಹಕ ಅಥವಾ ಸುತ್ತುವರಿಕೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅದರ ಮಿತಿಗೊಳಿಸುವ ಗುಂಪಿನಲ್ಲಿ ಸಾಮರ್ಥ್ಯ ಇಲ್ಲದೆ ಪ್ರಾರಂಭಿಸಿದ್ದರೆ, ಯಾವುದೇ AppArmor ಬದಲಾವಣೆ ಅದನ್ನು ಮರಳಿ ತರಲಾರದು, ಮತ್ತು ಪ್ರೊಫೈಲ್‌ಗೆ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸೇರಿಸುವುದು ಕರ್ನಲ್ ಗೌರವಿಸದ ಉದ್ದೇಶವನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಅಷ್ಟೆ.

ನೀತಿಯನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ವಿಶೇಷಾಧಿಕಾರ ಸ್ಥಿತಿಯನ್ನು ಓದಿ

ಸಕ್ರಿಯ ಎಂದು ನೀವು ನಂಬುವ ಸಂರಚನೆಯಿಂದ ಅಲ್ಲ, ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಆರಂಭಿಸಿ. ಸ್ಥಿತಿ ಫೈಲ್ ಐದು ಸಾಮರ್ಥ್ಯ ಮುಖವಾಡಗಳನ್ನು ಮತ್ತು no-new-privileges ಧ್ವಜವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff ಕರೆಗೆ ಮುಖ್ಯವಾದ ಗುಂಪು: CapBnd ನಲ್ಲಿದ್ದು CapEff ನಲ್ಲಿ ಇಲ್ಲದ ಸಾಮರ್ಥ್ಯವನ್ನು ಮೇಲ್ಛಾವಣಿ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಸದ್ಯಕ್ಕೆ ಹಿಡಿದಿಲ್ಲ. CapAmb ಬೈನರಿ ಸಾಮಾನ್ಯ setuid ಅರ್ಥದಲ್ಲಿ ವಿಶೇಷಾಧಿಕಾರ ಹೊಂದಿಲ್ಲದಿದ್ದಾಗ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಪರಿಸರ ಸಾಮರ್ಥ್ಯಗಳೇ ಸೇವೆಯು ಫೈಲ್ ಸಾಮರ್ಥ್ಯಗಳಿಲ್ಲದೆ exec ಅನ್ನು ದಾಟಿ ವಿಶೇಷಾಧಿಕಾರ ಉಳಿಸಿಕೊಳ್ಳುವ ದಾರಿ. CapInh exec ಅನ್ನು ದಾಟಿ ಆನುವಂಶಿಕವಾಗಿ ಬರಬಹುದಾದ ಬಿಟ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಚಲಾಯಿಸುವ ಫೈಲ್‌ನ ಆನುವಂಶಿಕ ಗುಂಪು ಅನುಮತಿಸಿದಾಗ ಮಾತ್ರ, ಆದ್ದರಿಂದ ಅಲ್ಲಿನ ಒಂದು ಬಿಟ್ ತಾನಾಗಿಯೇ ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ.

ನಂತರ ಯಾವ ಪ್ರೊಫೈಲ್ ನಿಜವಾಗಿ ಜೋಡಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪ್ರಕ್ರಿಯೆಯು ನೀವು ನಿರೀಕ್ಷಿಸದ ಪ್ರೊಫೈಲ್ ಹೆಸರಿನಿಂದ ಸೀಮಿತವಾಗಿರಬಹುದು, ವಿಶೇಷವಾಗಿ ವಿತರಣೆಯು ತನ್ನದೇ ಘಟಕ ಫೈಲ್ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಕಳುಹಿಸಿದಾಗ, ಮತ್ತು /proc/PID/attr/current ಓದುವುದು ಅದನ್ನು ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ತೀರ್ಮಾನಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸಂಪಾದಿತ ಫೈಲ್ ಅನ್ನು ಕರ್ನಲ್ ವರದಿ ಮಾಡುವ ಪ್ರೊಫೈಲ್‌ನೊಂದಿಗೆ ಹೋಲಿಸುವುದು ಕಾರಣವನ್ನು ಸರಿಪಡಿಸುವುದಕ್ಕೂ ಯಾರೂ ಲೋಡ್ ಮಾಡದ ಫೈಲ್ ಸಂಪಾದಿಸುವುದಕ್ಕೂ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

ಆಡಿಟ್ ಜಾಡು ಹೇಳಿದಾಗ ಮಾತ್ರ ಸಾಮರ್ಥ್ಯದ ನಿಯಮ ಸೇರಿಸಿ

ಕರ್ನಲ್ ಮತ್ತು ಆಡಿಟ್ ದಾಖಲೆಗಳು ನಿರಾಕರಿಸಿದ ಪದರವನ್ನು ಹೆಸರಿಸುತ್ತವೆ. ಕಾರ್ಯಾಚರಣೆ capable ಮತ್ತು ಹೆಸರು sys_chroot ಹೊಂದಿರುವ, ಅದನ್ನು ಉತ್ಪಾದಿಸಿದ ಪ್ರೊಫೈಲ್ ಜೊತೆಗಿರುವ ನಿರಾಕರಣೆಯನ್ನು ಹುಡುಕಿ. ಆ ದಾಖಲೆ ಇದ್ದರೆ, ಪ್ರಕ್ರಿಯೆಯು ಈಗಾಗಲೇ ಸಾಮರ್ಥ್ಯ ಹೊಂದಿತ್ತು ಮತ್ತು AppArmor ನಿರಾಕರಿಸಿತು, ಮತ್ತು ಗುರಿಯ ಬದಲಾವಣೆ ನಿಜವಾದ ಪ್ರೊಫೈಲ್ ಒಳಗಿನ ಸಾಮರ್ಥ್ಯದ ನಿಯಮ:

capability sys_chroot,

ಅದನ್ನು ನಿಜವಾಗಿ ಜೋಡಿಸಲಾದ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ತುಣುಕಾಗಿ ಇರಿಸಿ, ಮತ್ತು ಕೀವರ್ಡ್ ಅನ್ನು ಸಂಬಂಧವಿಲ್ಲದ ಪಾಠದಿಂದ ನಿಯಮ ನಕಲಿಸುವ ಬದಲು apparmor.d ಪ್ರೊಫೈಲ್ ಉಲ್ಲೇಖ ದೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ. ಹಂಚಿದ include ಒಳಗೆ ಹಾಕುವುದು ಅದನ್ನು ಆ ಫೈಲ್ ಎಳೆದುಕೊಳ್ಳುವ ಪ್ರತಿಯೊಂದು ಸೀಮಿತ ಕಾರ್ಯಕ್ರಮಕ್ಕೂ ನೀಡುತ್ತದೆ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಅನ್ನು complain ಮೋಡ್‌ಗೆ ಬದಲಿಸುವುದು ಇದನ್ನು ಪರಿಹರಿಸುವ ಬದಲು ಮುಂದಿನ ನಿರಾಕರಣೆಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಪ್ರೊಫೈಲ್ ನಿಯಮ ನೀತಿ ನಿರಾಕರಣೆಯನ್ನು ತೆಗೆಯುತ್ತದೆ; ಅದು ವಿಶೇಷಾಧಿಕಾರವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪರಿಣಾಮಕಾರಿ ಗುಂಪಿನಲ್ಲಿ CAP_SYS_CHROOT ಎಂದಿಗೂ ಇಲ್ಲದ ಪ್ರಕ್ರಿಯೆ ನಿಯಮ ಇದ್ದರೂ ವಿಫಲವಾಗುತ್ತದೆ.

ಆಡಿಟ್ ದಾಖಲೆ AppArmor ನಿರಾಕರಣೆಯನ್ನು ಲವಲೇಶವೂ ತೋರಿಸದಿದ್ದರೆ, ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆಯನ್ನು ನಿಲ್ಲಿಸಿ. ನೀವು ರುಜುವಾತುಗಳ ಸಮಸ್ಯೆಯನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಉಳಿದ ಕೆಲಸ ಘಟಕ ಫೈಲ್ ಅಥವಾ ಮೂಲ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿದೆ, ನೀತಿ ಭಾಷೆಯಲ್ಲಿ ಅಲ್ಲ.

ಸೇವಾ ನಿರ್ವಾಹಕ ತನ್ನದೇ ಮೇಲ್ಛಾವಣಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ

systemd ಪ್ರತಿ ಸೇವೆಗೂ ಸಾಮರ್ಥ್ಯಗಳ ಮಿತಿಗೊಳಿಸುವ ಗುಂಪನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಮತ್ತು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಆ ಗುಂಪು ಸಂಕುಚಿತವಾಗಿದೆ. ಅಲ್ಲಿ ಹೊರಗಿಟ್ಟದ್ದು ಪ್ರೊಫೈಲ್ ಏನೇ ಹೇಳಿದರೂ ಪ್ರಕ್ರಿಯೆಗೆ ಲಭ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಕಠಿಣಗೊಳಿಸಿದ ಘಟಕಗಳು ಡೀಮನ್ ಅನ್ನು ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದಾಗ ಕೆಲಸ ಮಾಡಿದ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. ಸಂಬಂಧಿತ ನಿರ್ದೇಶನಗಳನ್ನು ಘಟಕದಲ್ಲಿ ಓದುವುದು ಸುಲಭ ಮತ್ತು ಅನ್ವಯವು ವಿಫಲತೆ ವರದಿ ಮಾಡಿದಾಗ ಕಣ್ಣಿಗೆ ಬೀಳದಿರುವುದೂ ಸುಲಭ. ವಿತರಣಾ ಪ್ಯಾಕೇಜ್ ಒದಗಿಸುವ drop-in ಗಳು ಯಾರೂ ಸಂರಚಿಸಿದ ನೆನಪಿಲ್ಲದ ಮೇಲ್ಛಾವಣಿಯ ಸಾಮಾನ್ಯ ಮೂಲ.

ಮೇಲ್ಛಾವಣಿ ಎತ್ತುವುದು ಮತ್ತು ಸಾಮರ್ಥ್ಯ ನೀಡುವುದು ಎರಡು ಬದಲಾವಣೆಗಳು, ಒಂದಲ್ಲ. ಮಿತಿಗೊಳಿಸುವ ಗುಂಪಿನ ನಮೂದು ಪ್ರಕ್ರಿಯೆ ಸಾಮರ್ಥ್ಯ ಹಿಡಿಯಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ; ಅದು ಅದನ್ನು ಪರಿಣಾಮಕಾರಿ ಗುಂಪಿಗೆ ಸೇರಿಸುವುದಿಲ್ಲ, ಮತ್ತು NoNewPrivs ಉಳಿದೆಲ್ಲವೂ ಹೊಂದಿಕೆಯಾದರೂ ನಂತರದ ಏರಿಕೆ ಯಶಸ್ವಿಯಾಗುವುದನ್ನು ತಡೆಯಬಹುದು. ಕಾರ್ಯಾಚರಣೆಗೆ ಬೇಕಾದದ್ದನ್ನು ಮಾತ್ರ ಸೇರಿಸಿ, ಉಳಿದ ಕಠಿಣಗೊಳಿಸುವಿಕೆಯನ್ನು ಉಳಿಸಿ, ಮತ್ತು ಒಂದು ಕರೆ ದಾಟಲು ಎಲ್ಲಾ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುವ ಚಿಕ್ಕದಾರಿಯನ್ನು ನಿರಾಕರಿಸಿ.

ಇಲ್ಲಿ ಕ್ರಮವೂ ಮುಖ್ಯ. ಮೊದಲು ಘಟಕದ ಮೇಲ್ಛಾವಣಿ ಬದಲಿಸಿ, CapEff ಈಗ ಆ ಬಿಟ್ ಹೊಂದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಆಮೇಲೆ ಮಾತ್ರ AppArmor ಇನ್ನೂ ನಿರಾಕರಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ಎರಡೂ ಬದಲಾವಣೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಮಾಡುವುದು ವಿಫಲತೆ ಮುಂದುವರಿದರೆ ನಿಮ್ಮನ್ನು ಮತ್ತೆ ಊಹೆಯಲ್ಲಿ ಬಿಡುತ್ತದೆ.

ನಿರಾಕರಣೆ ತೊಲಗಿದ ನಂತರ ಸೆರೆಮನೆಯನ್ನೇ ಪರಿಶೀಲಿಸಿ

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

chroot ಏನನ್ನು ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದೂ ಸಹಾಯಕ. ಇದು ಪಥದ ಗಡಿ, sandbox ಅಲ್ಲ: ವಿಶೇಷಾಧಿಕಾರ ಉಳಿಸಿಕೊಂಡ ಪ್ರಕ್ರಿಯೆ ಅದರಿಂದ ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದು, ಆದ್ದರಿಂದ ಸಾಮರ್ಥ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಕರೆಯ ನಂತರ ಬಿಡಲಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಸೀಮಿತಗೊಳಿಸುವಿಕೆ ಡೀಮನ್ ಸುತ್ತಲೂ ಇರಬೇಕು. AppArmor ಪ್ರೊಫೈಲ್, ಸಾಮರ್ಥ್ಯಗಳ ಮಿತಿಗೊಳಿಸುವ ಗುಂಪು ಮತ್ತು ಫೈಲ್‌ಸಿಸ್ಟಮ್ ನಿರ್ಬಂಧಗಳನ್ನು ಒಟ್ಟಿಗೆ ಉಳಿಸುವುದೇ ಈ ಅಭ್ಯಾಸದ ಉದ್ದೇಶ, ಸೇವೆ ಪ್ರಾರಂಭವಾದ ಮೇಲೆ ತೆಗೆಯುವ ಉಳಿಕೆ ಅಲ್ಲ.

ನಿರ್ಧಾರದ ನಿಯಮ ಚಿಕ್ಕದು. ಆಡಿಟ್ ದಾಖಲೆ AppArmor ಎಂದು ಹೆಸರಿಸಿದರೆ, ಜೋಡಿಸಲಾದ ಪ್ರೊಫೈಲ್‌ಗೆ ಒಂದು ಸಾಮರ್ಥ್ಯದ ನಿಯಮ ಸೇರಿಸಿ. ಪರಿಣಾಮಕಾರಿ ಗುಂಪು ಖಾಲಿಯಿದ್ದರೆ, ಘಟಕದ ಮೇಲ್ಛಾವಣಿ ಮತ್ತು ವಿಶೇಷಾಧಿಕಾರ ಬಿಡುವ ಕ್ರಮವನ್ನು ಸರಿಪಡಿಸಿ. ಪ್ರೊಫೈಲ್ ನೀವು ಸಂಪಾದಿಸಿದ್ದಲ್ಲದಿದ್ದರೆ, ಸಂಪಾದನೆ ನಿಲ್ಲಿಸಿ ನಿಜವಾದದ್ದನ್ನು ಹುಡುಕಿ.