การเข้าถึง systemctl ถูกปฏิเสธเมื่อรูท


16

เมื่อฉันวิ่ง

sudo systemctl disable avahi-daemon.socket

ฉันเข้าใจ

Failed to execute operation: Access denied

แต่มันทำงานเหมือนรูทการเข้าถึงถูกปฏิเสธได้อย่างไร (CentOS 7)


คุณกำลังทำงานในภาชนะบรรจุเช่น Docker หรือ LXC หรือ LXD หรือไม่? คุณรู้หรือไม่ว่าคุณอยู่ในภาชนะหรือไม่?
allquixotic

ฉันใช้ CentOS ใหม่ติดตั้งใน VirtualBox ที่นับเป็นภาชนะบรรจุหรือไม่?
spraff

ไม่ VirtualBox ไม่ใช่คอนเทนเนอร์ แต่เป็นเครื่องเสมือน มันแตกต่างกันโดยพื้นฐาน เป็นไปได้มากที่คุณจะต้องพยายามjournalctl -xeหาสาเหตุว่าเกิดอะไรขึ้น
allquixotic

1
โปรดทราบว่าข้อความแสดงข้อผิดพลาดนี้ ("ล้มเหลวในการดำเนินการการดำเนินการ: ปฏิเสธการเข้าถึง") สามารถเกิดขึ้นได้เมื่อพยายามเข้าถึงบริการที่ไม่มีอยู่ในโหมดบังคับใช้ ในโหมดที่อนุญาตคุณจะได้รับ "ล้มเหลวในการดำเนินการ: ไม่มีไฟล์หรือไดเรกทอรีดังกล่าว"
danmichaelo

คำตอบ:


23

ฉันทำงานบน 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
spraff

คุณสามารถลองปิดการใช้งานโหมดบังคับใช้ selinux ได้หรือไม่? setenforce 0
Elouan Keryell- แม้

1
systemctl disable avahi-daemon.socketประสบความสำเร็จหลังจากที่setenforce 0ไม่มีsystemctl daemon-reexec(และฉันรู้แล้วว่าตอนนี้unmaskคำสั่งของคุณไม่ใช่ของฉัน :-)) มันโอเคที่จะทำสิ่งนี้และsetenforce 1หลังจากนั้นหรือไม่?
spraff

@spraff ฉันไม่รู้ฉันเป็นน้องใหม่ของ SELinux ฮ่า ฉันพูดถึงsetenforce 0ในคำตอบของฉันแล้ว
Elouan Keryell- แม้

1
setenforce 0กรุณาอย่า นี่เป็นวิธีปฏิบัติที่ไม่ดีในสภาพแวดล้อมการผลิต กรุณาใช้systemctl daemon-reexecแทน
Younes

10

ในกรณีของฉันฉันเพิ่งอัพเกรดsystemdและsystemctlคำสั่งใด ๆล้มเหลว:

# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied

อย่างไรก็ตามตามinitmanpage คุณสามารถทำสิ่งเดียวกันโดยส่งSIGTERMdaemon ที่ทำงานเป็น PID 1 ซึ่งทำงาน:

kill -TERM 1

นี่เป็นการโหลด daemon ใหม่หลังจากที่systemctlคำสั่งทั้งหมดเริ่มทำงานอีกครั้ง


1
ขอบคุณ แก้ไขปัญหาที่เกิดขึ้นหลังจากอัพเกรดอาร์คลินุกซ์มาเป็นเวลานาน
buergi

1
ทำงานบน Ubuntu 18.10 - ขอบคุณ!
Roy Shilkrot

1

ทั้งสองวิธีไม่ได้ผลสำหรับฉัน มันกลับกลายเป็นว่ามีเครื่องหมาย = หายไปหนึ่งบรรทัดในไฟล์. service ของฉัน ฉันค้นพบสิ่งนี้โดยการดู / var / log / messages และเห็นข้อผิดพลาดที่นั่นอธิบายเพิ่มเติม ดังนั้นการเข้าถึงถูกปฏิเสธทำให้เข้าใจผิด มันไม่ใช่ปัญหาด้านความปลอดภัยจริงๆ


3
คุณควรให้รายละเอียดเพิ่มเติมเกี่ยวกับวิธีแก้ปัญหานี้ ตัวอย่างเช่นคุณพูดถึงข้อความแสดงข้อผิดพลาด verbose มากขึ้น แต่ไม่ได้ระบุสิ่งที่ messag ข้อผิดพลาดเป็นสิ่งที่แน่นอน หากไม่มีข้อมูลนี้สิ่งนี้จะเป็นความคิดเห็นที่ดีขึ้นเพราะคำตอบนี้หากไม่มีข้อมูลนี้จะไม่สมบูรณ์
Ramhound

ไฟล์บันทึกใดแสดงข้อความ
rogerdpack
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.