บัญชี NIX หลายบัญชีพร้อม UID ที่เหมือนกัน

ฉันอยากรู้ว่ามีพฤติกรรมที่คาดหวังมาตรฐานหรือไม่และถือว่าเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่เมื่อสร้างมากกว่าหนึ่งบัญชีบน Linux / Unix ที่มี UID เดียวกัน ฉันได้ทำการทดสอบบางอย่างกับ RHEL5 กับสิ่งนี้และมันทำงานได้ตามที่คาดไว้ แต่ฉันไม่รู้ว่าฉันกำลังล่อลวงโชคชะตาโดยใช้เคล็ดลับนี้หรือไม่

ตัวอย่างเช่นสมมติว่าฉันมีสองบัญชีที่มีรหัสเดียวกัน:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

สิ่งนี้หมายความว่าอะไร:

• ฉันสามารถเข้าสู่แต่ละบัญชีโดยใช้รหัสผ่านของตนเอง
• ไฟล์ที่ฉันสร้างจะมี UID เดียวกัน
• เครื่องมือเช่น "ls -l" จะแสดงรายการ UID เป็นรายการแรกในไฟล์ (a1 ในกรณีนี้)
• ฉันหลีกเลี่ยงการอนุญาตหรือปัญหาความเป็นเจ้าของระหว่างสองบัญชีเพราะพวกเขาเป็นผู้ใช้เดียวกันจริงๆ
• ฉันได้รับการตรวจสอบการเข้าสู่ระบบสำหรับแต่ละบัญชีดังนั้นฉันจึงมีความละเอียดในการติดตามสิ่งที่เกิดขึ้นในระบบ

ดังนั้นคำถามของฉันคือ:

• ความสามารถนี้ได้รับการออกแบบหรือเป็นเพียงวิธีการทำงาน
• สิ่งนี้จะสอดคล้องกันในตัวแปร * nix หรือไม่?
• การปฏิบัตินี้เป็นที่ยอมรับหรือไม่?
• มีผลที่ไม่ตั้งใจต่อการฝึกนี้หรือไม่?

หมายเหตุแนวคิดที่นี่คือการใช้สิ่งนี้สำหรับบัญชีระบบและไม่ใช่บัญชีผู้ใช้ปกติ

ความคิดเห็นของฉัน:

ความสามารถนี้ได้รับการออกแบบหรือเป็นเพียงวิธีการทำงาน

มันถูกออกแบบมา ตั้งแต่ฉันเริ่มใช้ * NIX คุณสามารถวางผู้ใช้ในกลุ่มทั่วไปได้ ความสามารถในการมี UID เหมือนกันโดยไม่มีปัญหานั้นเป็นเพียงผลลัพธ์ที่ตั้งใจซึ่งอาจทำให้เกิดปัญหาหากจัดการอย่างไม่ถูกต้อง

สิ่งนี้จะสอดคล้องกันในตัวแปร * nix หรือไม่?

ฉันเชื่ออย่างนั้น

การปฏิบัตินี้เป็นที่ยอมรับหรือไม่?

ยอมรับว่าใช้โดยทั่วไปไม่ทางใดก็ทางหนึ่งใช่

มีผลที่ไม่ตั้งใจต่อการฝึกนี้หรือไม่?

นอกเหนือจากการตรวจสอบการเข้าสู่ระบบคุณไม่มีอะไรอื่น ยกเว้นว่าคุณต้องการเริ่มต้นด้วย

มันจะใช้ได้กับยูนิกซ์ทั้งหมดหรือไม่ ใช่.

เป็นเทคนิคที่ดีหรือไม่? ไม่ได้มีเทคนิคอื่น ๆ ที่ดีกว่า ตัวอย่างเช่นการใช้งานที่ถูกต้องของกลุ่มยูนิกซ์และการกำหนดค่า "sudo" ที่ควบคุมอย่างเข้มงวดสามารถบรรลุสิ่งเดียวกันได้

ฉันเคยเห็นสถานที่แห่งนี้ถูกใช้โดยไม่มีปัญหา ใน FreeBSD เป็นเรื่องปกติที่จะสร้างบัญชีรูทสำรองที่เรียกว่า "toor" (รูตสะกดหลัง) ซึ่งมี / bin / sh เป็นเชลล์เริ่มต้น วิธีนี้ถ้าเปลือกของรูทถูกทำให้ยุ่งเหยิงคุณยังสามารถเข้าสู่ระบบได้

ฉันไม่สามารถให้คำตอบที่ยอมรับได้สำหรับคำถามของคุณ แต่ บริษัท ของฉันทำสิ่งนี้มานานหลายปีกับผู้ใช้รูทและไม่เคยมีปัญหาใด ๆ เราสร้างผู้ใช้ 'kroot' (UID 0) ซึ่งมีเหตุผลเดียวที่มี / bin / ksh เป็นเชลล์แทนที่จะเป็น / bin / sh หรือ bin / bash ฉันรู้ว่า Oracle DBA ของเราทำสิ่งที่คล้ายกับผู้ใช้ของพวกเขามีชื่อผู้ใช้ 3 หรือ 4 คนต่อการติดตั้งทั้งหมดนี้มี ID ผู้ใช้เดียวกัน (ฉันเชื่อว่าสิ่งนี้ทำเพื่อแยกไดเรกทอรีหลักกับผู้ใช้แต่ละคน สิบปีบน Solaris และ Linux ฉันคิดว่ามันทำงานได้ตามที่ออกแบบไว้

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

ความสามารถนี้ได้รับการออกแบบหรือเป็นเพียงวิธีการทำงาน

ออกแบบด้วยวิธีนั้น

สิ่งนี้จะสอดคล้องกันในตัวแปร * nix หรือไม่?

มันควรจะใช่

การปฏิบัตินี้เป็นที่ยอมรับหรือไม่?

ขึ้นอยู่กับความหมายของคุณ สิ่งประเภทนี้ตอบสนองต่อปัญหาที่เฉพาะเจาะจงอย่างมาก (ดูบัญชีผู้ใช้ root / toor) ที่อื่นและคุณกำลังถามหาปัญหาที่โง่ในอนาคต หากคุณไม่แน่ใจว่านี่เป็นทางออกที่ถูกต้องหรือไม่

มีผลที่ไม่ตั้งใจต่อการฝึกนี้หรือไม่?

เป็นเรื่องทั่วไปที่กำหนดเองเพื่อใช้กับชื่อผู้ใช้และ UID แทนกันได้ ตามที่คนอื่นไม่กี่คนชี้ให้เห็นการตรวจสอบการเข้าสู่ระบบ / กิจกรรมจะไม่ถูกต้อง นอกจากนี้คุณยังจะต้องตรวจสอบพฤติกรรมของสคริปต์ / โปรแกรมที่เกี่ยวข้องกับผู้ใช้ที่เกี่ยวข้อง (useradd, usermod, สคริปต์ผู้ใช้, distro สคริปต์การบำรุงรักษาเป็นระยะ ๆ ของคุณ)

คุณพยายามทำอะไรกับสิ่งนี้ซึ่งจะไม่สามารถทำได้โดยการเพิ่มผู้ใช้สองคนนี้ลงในกลุ่มใหม่และให้สิทธิ์ที่คุณต้องการแก่กลุ่มนั้น

มีผลที่ไม่ตั้งใจต่อการฝึกนี้หรือไม่?

มีปัญหาหนึ่งที่ฉันรับรู้อยู่ Cron เล่นได้ไม่ดีกับนามแฝง UID นี้ ลองเรียกใช้ "crontab -i" จากสคริปต์ Python เพื่ออัปเดตรายการ cron จากนั้นเรียกใช้ "crontab -e" ในเปลือกเพื่อแก้ไขเดียวกัน

โปรดสังเกตว่าตอนนี้ cron (vixie ฉันคิดว่า) จะอัปเดตรายการเดียวกันสำหรับทั้ง a1 และ a2 (ใน / var / spool / cron / a1 และ / var / spool / cron / a2)

นี่เป็นพฤติกรรมที่คาดหวังในการแจกแจงทั้งหมดที่ฉันได้เห็นและเป็นเคล็ดลับทั่วไปที่ 'ศัตรู' ใช้เพื่อซ่อนบัญชีที่มีการเข้าถึงรูท

มันไม่ได้มาตรฐานอย่างแน่นอน (ฉันไม่ได้เห็นสิ่งนี้ในการเล่นที่ใดก็ได้) แต่ไม่ควรมีเหตุผลใด ๆ ที่คุณไม่สามารถใช้สิ่งนี้ในสภาพแวดล้อมของคุณเองหากคุณเห็นว่าเหมาะสม

gotcha เพียงอย่างเดียวที่อยู่ในใจในตอนนี้ก็คือการตรวจสอบอาจทำได้ยาก หากคุณมีผู้ใช้สองคนที่มี uid / gid เดียวกันฉันเชื่อว่าคุณจะมีเวลาในการพิจารณาว่าผู้ใช้คนใดทำอะไรเมื่อคุณวิเคราะห์บันทึก

การแชร์ ID กลุ่มหลักนั้นเป็นเรื่องปกติดังนั้นคำถามจะหมุนรอบUIDจริงๆ

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

สิ่งสำคัญที่ฉันต้องระวังคือสิ่งต่าง ๆ เช่นการลบผู้ใช้คนหนึ่ง - โปรแกรมอาจสับสนและลบทั้งผู้ใช้หรือไฟล์ที่เป็นของทั้งสองหรือสิ่งที่คล้ายกัน

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

BTW - คำถาม / คำตอบนี้อัปเดตสำหรับระบบปฏิบัติการปัจจุบัน

การอ้างอิงจากredhat: การจัดการการกำหนด UID และ GID หมายเลขเฉพาะนั้นจะอธิบายการใช้ UID และ GID และการจัดการและเครื่องกำเนิดไฟฟ้า (เซิร์ฟเวอร์ ID)

ต้องสร้างค่า UID และ GID แบบสุ่มและให้แน่ใจว่าแบบจำลองไม่เคยสร้างค่า UID หรือ GID เดียวกัน ความต้องการหมายเลข UID และ GID ที่ไม่ซ้ำใครอาจจะข้ามโดเมน IdM ได้หากองค์กรเดียวมีหลายโดเมนที่แตกต่างกัน

ในทำนองเดียวกันยูทิลิตี้ที่อนุญาตให้เข้าถึงระบบอาจทำงานไม่แน่นอน (อ้างอิงเดียวกัน):

หากสองรายการถูกกำหนดหมายเลข ID เดียวกันเฉพาะรายการแรกเท่านั้นที่ถูกส่งคืนในการค้นหาหมายเลขนั้น

ปัญหาเกิดขึ้นเมื่อแนวคิดของ "ครั้งแรก" ไม่ชัดเจน ขึ้นอยู่กับบริการที่ติดตั้งชื่อผู้ใช้อาจถูกเก็บไว้ในแฮชขนาดตัวแปรที่จะส่งคืนชื่อผู้ใช้ที่แตกต่างกันตามปัจจัยที่ไม่สอดคล้องกัน (ฉันรู้ว่านี่เป็นความจริงเพราะบางครั้งฉันพยายามใช้ชื่อผู้ใช้ 2 ชื่อ w / หนึ่ง ID ชื่อหนึ่งเป็นชื่อผู้ใช้ในท้องถิ่นและอีกชื่อหนึ่งคือชื่อโดเมนชื่อผู้ใช้ที่ฉันต้องการแมปกับ UID (ซึ่งฉันพูดถึงในที่สุด) วิธีที่แตกต่างกันโดยสิ้นเชิง) แต่ฉันสามารถเข้าสู่ระบบด้วย "usera" ทำ "who" หรือ "id" และดู "userb" หรือ "usera" - สุ่ม

มีอินเทอร์เฟซสำหรับดึงค่าหลายค่าของ UID จากกลุ่ม (กลุ่มที่มี GID เดียวได้รับการออกแบบให้เชื่อมโยงกับหลาย UID's) แต่ไม่มีส่วนต่อประสานแบบพกพาที่จะส่งคืนรายการชื่อสำหรับ UID เดียวดังนั้นใครก็ตามที่คาดหวังเหมือนกัน หรือพฤติกรรมที่คล้ายกันระหว่างระบบหรือแม้แต่แอพพลิเคชั่นในระบบเดียวกันอาจแปลกใจอย่างไม่มีความสุข

ใน Sun (oracle ตอนนี้) yp (yellowpages) หรือ NIS (NetworkInformationServices) นอกจากนี้ยังมีการอ้างอิงจำนวนมากถึงข้อกำหนดของความเป็นเอกลักษณ์ มีการตั้งค่าฟังก์ชันและเซิร์ฟเวอร์พิเศษเพื่อจัดสรรID ที่ไม่ซ้ำกันในหลายเซิร์ฟเวอร์และโดเมน (ตัวอย่างคือuid_allocd, gid_allocd - UID และ GID allocator daemons manpage

แหล่งที่มาที่สามที่อาจตรวจสอบคือเอกสารเซิร์ฟเวอร์ของ Microsoft สำหรับการจับคู่บัญชี NFS NFS เป็นโปรโตคอลแชร์ไฟล์ที่ใช้ระบบปฏิบัติการยูนิกซ์และพวกเขาอธิบายถึงวิธีการดูแลสิทธิ์และการเข้าถึงไฟล์โดย ID ที่นั่นพวกเขาเขียน:

• โพสต์ นี่เป็นจำนวนเต็มที่ไม่ได้ลงนามที่ใช้โดยระบบปฏิบัติการ UNIX เพื่อระบุผู้ใช้และต้องไม่ซ้ำกันในไฟล์ passwd

• GID นี่เป็นจำนวนเต็มที่ไม่ได้ลงนามที่ใช้โดยเคอร์เนล UNIX เพื่อระบุกลุ่มและจะต้องไม่ซ้ำกันในไฟล์กลุ่ม หน้าการจัดการ MS-NFS

ในขณะที่ระบบปฏิบัติการบางระบบอาจอนุญาตให้ใช้ชื่อ / UID หลายตัว (อนุพันธ์ของ BSD หรืออาจ?) ระบบปฏิบัติการส่วนใหญ่ขึ้นอยู่กับสิ่งนี้ว่าเป็นลักษณะเฉพาะและอาจทำงานไม่แน่นอนเมื่อพวกเขาไม่ได้

หมายเหตุ - ฉันกำลังเพิ่มหน้านี้ในฐานะคนที่อ้างถึงรายการวันที่นี้เพื่อรองรับอุปกรณ์ทันสมัยเพื่อรองรับ UID / GID ที่ไม่ซ้ำกัน ... ซึ่งส่วนใหญ่ทำไม่ได้

ฉันก็ไม่รู้เหมือนกันว่ามันเป็นความคิดที่ดีหรือไม่ แต่ฉันใช้พฤติกรรมดังกล่าวในบางที่ ส่วนใหญ่เป็นสำหรับบัญชีที่ใช้เพื่อเข้าถึงเซิร์ฟเวอร์ ftp / sftp และปรับปรุงเนื้อหาเว็บไซต์ ดูเหมือนจะไม่ทำลายอะไรเลยและดูเหมือนว่าจะทำให้การจัดการสิทธิ์ง่ายขึ้นแล้วมันจะมีหลายบัญชี

เพิ่งพบปัญหา (ค่อนข้างคลุมเครือ) อันเนื่องมาจากการใช้หลายบัญชีด้วย UID เดียวกันและคิดว่าฉันจะแบ่งปันมันเป็นตัวอย่างว่าทำไมมันถึงไม่ใช่วิธีปฏิบัติที่ดี

ในกรณีของฉันผู้ขายตั้งค่าเซิร์ฟเวอร์ฐานข้อมูล Informix และเว็บแอปพลิเคชันเซิร์ฟเวอร์ใน RHEL 7 ในระหว่างการตั้งค่าบัญชี "root" พร้อม UID 0 หลายบัญชีถูกสร้างขึ้น (อย่าถามฉันว่าทำไม) นั่นคือ "root", "user1" และ "user2" ซึ่งทั้งหมดมี UID 0

หลังจากนั้นเซิร์ฟเวอร์ RHEL 7 ได้เข้าร่วมกับโดเมน Active Directory โดยใช้ winbind ณ จุดนี้เซิร์ฟเวอร์ Informix DB ไม่สามารถเริ่มต้นได้อีกต่อไป ทำงานล้มเหลวด้วยข้อผิดพลาดบอกว่าหนึ่งoninit"Must be a DBSA to run this program"

นี่คือสิ่งที่เราพบขณะแก้ไขปัญหา:

1. การเรียกใช้id rootหรือgetent passwd 0(เพื่อแก้ไข UID 0 เป็นชื่อผู้ใช้) บนระบบที่เข้าร่วม Active Directory จะส่งคืน "user1" หรือ "user2" แบบสุ่มแทน "root"

2. เห็นได้ชัดว่า Informix อาศัยการเปรียบเทียบสตริงเพื่อตรวจสอบว่าชื่อผู้ใช้ที่เป็นข้อความของผู้ใช้ที่เริ่มต้นนั้นคือ "root" และจะล้มเหลวเป็นอย่างอื่น

3. โดยไม่ต้อง winbind id rootและgetent passwd 0จะคืนค่า "root" เป็นชื่อผู้ใช้อย่างสม่ำเสมอ

การแก้ไขคือการปิดใช้งานการแคชและการคงอยู่ใน/etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

หลังจากการเปลี่ยนแปลงนี้ UID 0 ได้รับการแก้ไขอีกครั้งเป็น "root" และ Informix สามารถเริ่มต้นได้

หวังว่านี่จะเป็นประโยชน์กับใครบางคน