เมื่อฉันวิ่ง
sudo systemctl disable avahi-daemon.socket
ฉันเข้าใจ
Failed to execute operation: Access denied
แต่มันทำงานเหมือนรูทการเข้าถึงถูกปฏิเสธได้อย่างไร (CentOS 7)
journalctl -xe
หาสาเหตุว่าเกิดอะไรขึ้น
เมื่อฉันวิ่ง
sudo systemctl disable avahi-daemon.socket
ฉันเข้าใจ
Failed to execute operation: Access denied
แต่มันทำงานเหมือนรูทการเข้าถึงถูกปฏิเสธได้อย่างไร (CentOS 7)
journalctl -xe
หาสาเหตุว่าเกิดอะไรขึ้น
คำตอบ:
ฉันทำงานบน CentOS 7 และมีปัญหาที่คล้ายกัน:
# systemctl unmask tmp.mount
Failed to execute operation: Access denied
การปฏิเสธเกี่ยวข้องกับ SELinux นี่อาจเป็นกรณีของคุณหากคุณใช้งาน SELinux ในenforcing
โหมด:
# getenforce
Enforcing
ในกรณีของฉันsystemctl
ข้อผิดพลาดทำให้เกิดการUSER_AVC
ปฏิเสธในไฟล์บันทึกของ SELinux /var/log/audit/audit.log
:
type=USER_AVC msg=audit(1475497680.859:2656): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { enable } for auid=0 uid=0 gid=0 path="/dev/null" cmdline="systemctl unmask tmp.mount" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:null_device_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
บทความนี้ระบุว่าเป็นเพราะข้อผิดพลาดใน systemd และให้การแก้ไข:
systemctl daemon-reexec
หากข้างต้นไม่ทำงานคุณสามารถตั้งค่าโหมด SELinux เป็นpermissive
:
setenforce 0
และควรทำงานได้ดี อย่างไรก็ตามโซลูชันที่ 2 นี้มีผลกระทบด้านความปลอดภัย
Removed symlink
และหลังจากนั้นก็systemctl disable avahi-daemon.socket
ล้มเหลวเหมือนเดิมสร้างบรรทัดเดียวกันในaudit.log
setenforce 0
systemctl disable avahi-daemon.socket
ประสบความสำเร็จหลังจากที่setenforce 0
ไม่มีsystemctl daemon-reexec
(และฉันรู้แล้วว่าตอนนี้unmask
คำสั่งของคุณไม่ใช่ของฉัน :-)) มันโอเคที่จะทำสิ่งนี้และsetenforce 1
หลังจากนั้นหรือไม่?
setenforce 0
ในคำตอบของฉันแล้ว
setenforce 0
กรุณาอย่า นี่เป็นวิธีปฏิบัติที่ไม่ดีในสภาพแวดล้อมการผลิต กรุณาใช้systemctl daemon-reexec
แทน
ในกรณีของฉันฉันเพิ่งอัพเกรดsystemd
และsystemctl
คำสั่งใด ๆล้มเหลว:
# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied
อย่างไรก็ตามตามinit
manpage คุณสามารถทำสิ่งเดียวกันโดยส่งSIGTERM
daemon ที่ทำงานเป็น PID 1 ซึ่งทำงาน:
kill -TERM 1
นี่เป็นการโหลด daemon ใหม่หลังจากที่systemctl
คำสั่งทั้งหมดเริ่มทำงานอีกครั้ง
ทั้งสองวิธีไม่ได้ผลสำหรับฉัน มันกลับกลายเป็นว่ามีเครื่องหมาย = หายไปหนึ่งบรรทัดในไฟล์. service ของฉัน ฉันค้นพบสิ่งนี้โดยการดู / var / log / messages และเห็นข้อผิดพลาดที่นั่นอธิบายเพิ่มเติม ดังนั้นการเข้าถึงถูกปฏิเสธทำให้เข้าใจผิด มันไม่ใช่ปัญหาด้านความปลอดภัยจริงๆ