“ ไม่สามารถตั้งค่ากลุ่มกระบวนการเทอร์มินัล” ระหว่าง su ให้ผู้ใช้อื่นเป็นเชลล์การเข้าสู่ระบบ

หมายเหตุ: โปรดอ่านข้อมูลอัพเดทที่เริ่มต้นด้วย "แก้ไข" ใกล้กับจุดกึ่งกลางของโพสต์นี้สภาพแวดล้อมและพื้นหลังของปัญหานี้มีการเปลี่ยนแปลง

ฉันได้ติดตั้ง Debian 6.0 แบบมาตรฐานที่นี่แล้วฉันจึงตัดสินใจปรับรุ่นเป็นที่เก็บการทดสอบ Debian ฉันทำสิ่งนี้โดยการสลับการอ้างอิงไปยัง Squos repos ใน source.list ของฉันเพื่อใช้ repos การทดสอบแทน

หลังจากแพคเกจติดตั้งและรีบูตฉันได้รับข้อผิดพลาดต่อไปนี้เมื่อพยายาม su - กับผู้ใช้รายอื่น:

root@skaia:~# su joebloggs -
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

หากฉันละเว้น - สิ่งนี้จะไม่เกิดขึ้น

โปรดทราบว่าผู้ใช้สามารถรูทได้อย่างถูกต้องซึ่งจะเกิดขึ้นเมื่อเปลี่ยนจากรูทเป็นบุคคลอื่นและใช้ - เพื่อรับสภาพแวดล้อมของผู้ใช้นั้น

Google ส่วนใหญ่ไม่มีประโยชน์ที่นี่ สิ่งเดียวที่ฉันสามารถค้นหาได้คือการอ้างอิงจากปี 2011 เกี่ยวกับsuxแพคเกจซึ่งดูเหมือนว่าได้รับการแก้ไขในเวลาเฉลี่ย

รูปลักษณ์และกลิ่นนี้เป็นเหมือนข้อผิดพลาดในการอัพเกรดสามารถแก้ไขได้โดยการปรับแต่งแพ็คเกจให้ถูกวิธี ฉันแค่ไม่รู้ว่าจะเริ่มจากตรงไหนระบบของฉันก็ทำงานได้ตามปกติและเป็นไปตามคาด

แก้ไข

นี่คือสิ่งที่เกิดขึ้นกับฉันบนเครื่องเดเบียนเสถียรตามที่อธิบายไว้ข้างต้น ไม่มีการอัปเกรดหรืออะไรก็ตามในเวลานี้เพียงแค่ทรงตัว

ใช่อีกหนึ่งปีต่อมา ยังไม่รู้เลยว่าปัญหาคืออะไร

นี่คือสิ่งที่ดูเหมือนตอนนี้ (ไม่ค่อยมีการเปลี่ยนแปลง):

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
terraria@skaianet:~$ tty
/dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/0
crw--w---- 1 root root 136, 0 Oct 10 19:21 /dev/pts/0
terraria@skaianet:~$ ls -l /dev/pts/
crw--w---- 1 root root 136, 0 Oct 10 19:21 0
crw--w---- 1 root root 136, 2 Sep 22 17:47 2
crw--w---- 1 root root 136, 3 Sep 26 19:30 3
c--------- 1 root root   5, 2 Sep  7 10:50 ptmx

strace ที่สร้างเช่นนี้:

root@skaianet:~$ strace -f -o tracelog su terraria -

.. นอกจากนี้ยังมีพฤติกรรมที่ทำให้สับสนอีกด้วย ข้อความเหล่านี้ค่อนข้างสับสน บางบรรทัดที่เลือก:

readlink("/proc/self/fd/0", "/dev/pts/0", 4095) = 10
#Error code 10? 
15503 open("/dev/tty", O_RDWR|O_NONBLOCK) = -1 ENXIO (No such device or address)
#Yes there is, and I can interact with it normally
15503 ioctl(255, TIOCGPGRP, [32561])    = -1 ENOTTY (Inappropriate ioctl for device)

ฉันได้เชื่อมโยงเอาท์พุทเต็มรูปแบบของเซสชัน strace นี้ - ทั้งหมดที่ฉันทำคือเรียกใช้คำสั่ง su จากนั้นกด ctrl + d ทันทีจากเทอร์มินัล

• su - usernameถูกตีความโดยคุณsuเพื่อหมายถึง "เรียกใช้เชลล์ของชื่อผู้ใช้เป็นเชลล์ล็อกอินแบบโต้ตอบ"
• su username -ถูกตีความโดยคุณsuเพื่อหมายถึง "เรียกใช้คำสั่งที่ไม่โต้ตอบ ( -) ในฐานะชื่อผู้ใช้ " ต่อไปนี้
• หลังทำงานเพียงเพราะ:
  • suอาร์กิวเมนต์การส่งต่อของคุณผ่านไปshสำหรับการวิเคราะห์คำ
  • shจะ-หมายถึง "ทำงานเป็นเปลือกเข้าสู่ระบบ (อ่าน/etc/profile, ... )"

แต่สิ่งที่คุณสนใจจริงๆก็คือ: ทำไมจึงไม่ใช่การโต้ตอบ ? การแชร์เทอร์มินัลการควบคุมระหว่างผู้ปกครองที่ได้รับสิทธิพิเศษและเด็กที่ไม่มีผู้ด้อยโอกาสทำให้คุณมีความเสี่ยงต่อ "การเพิ่มสิทธิพิเศษผลักดันกลับ TTY " หรือที่รู้จักกันในชื่อTIOCSTIข้อผิดพลาดดังนั้นเว้นแต่คุณต้องการsu แยกออกมาจริงๆ เมื่อคุณใช้su username -รูปแบบเหมาเอาว่าคุณไม่จำเป็นต้องสถานีควบคุมsu

กระบวนการที่มีเทอร์มินัลการควบคุมเท่านั้นที่สามารถมีผู้นำเซสชันที่จัดการกลุ่มกระบวนการ (ควบคุมงาน) การติดตามที่คุณระบุbashตรวจพบว่าไม่สามารถเป็นผู้นำเซสชันได้

คุณพูดถึง:

ตำแหน่งที่ได้รับคนแปลกหน้าคือทั้งสองรูปแบบทำงานได้ดีบน Ubuntu และ CentOS 6 อย่างไรก็ตามบน vanilla Debian เฉพาะรูปแบบแรกเท่านั้นที่ทำงานโดยไม่มีข้อผิดพลาด

สายพันธุ์ละเว้นชอบsuxและsudoมีอย่างน้อยสาม^[1]รุ่นsuบน Linux: coreutils, util-linuxและshadow-utilsจากการที่เดมา manpage ของหลังชี้ให้เห็น:

su เวอร์ชันนี้มีตัวเลือกการรวบรวมจำนวนมากซึ่งอาจมีการใช้งานเฉพาะบางไซต์เท่านั้น

และ Debian มาพร้อมกับธงold_debian_behavior; รุ่นอื่นอาจมีตัวเลือกการคอมไพล์เวลา / รันไทม์ที่คล้ายกัน เหตุผลสำหรับความแปรปรวนอื่นอาจเป็นไปได้ว่ามีบางอภิปราย^[2]เป็นไปได้ว่าsuควรจะเคยถูกใช้ในการวางสิทธิพิเศษด้วยวิธีนี้และไม่ว่าจะเป็น TIOCSTIข้อผิดพลาดดังนั้นจึงเป็นปัญหาที่ทุกคน (Redhat เดิมปิด "WONTFIX" )

[1]: แก้ไข: เพิ่มSimplePAMAppsและhardened-shadowเพื่อ

[2]: Solar Designer มีความคิดเห็น (เก่า) บางส่วนที่นั่นซึ่งฉันคิดว่าคุ้มค่าที่จะอ่าน

ฉันจะตรวจสอบความเป็นเจ้าของและการอนุญาตใน / dev / pts * หรือสำหรับการกำหนดค่าใหม่สำหรับ udev ที่เกี่ยวข้องกับอุปกรณ์ / dev / pts ที่ไม่ได้ถูกแทนที่ในระหว่างกระบวนการอัพเกรด

นอกจากนี้คุณยังสามารถลองค้นหาสิ่งที่ syscal กำลังสร้างข้อผิดพลาดโดยเรียกใช้เป็นรูท:

strace -f su - username 2>stderr.log