Nhiều tài khoản * NIX với UID giống hệt nhau

Tôi tò mò liệu có một hành vi dự kiến ​​tiêu chuẩn hay không và liệu nó có bị coi là thực tiễn xấu khi tạo nhiều tài khoản trên Linux / Unix có cùng UID hay không. Tôi đã thực hiện một số thử nghiệm trên RHEL5 với điều này và nó đã hoạt động như tôi mong đợi, nhưng tôi không biết liệu tôi có đang cám dỗ số phận bằng cách sử dụng thủ thuật này không.

Ví dụ: giả sử tôi có hai tài khoản có cùng ID:

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

Điều này có nghĩa là:

• Tôi có thể đăng nhập vào từng tài khoản bằng mật khẩu của riêng mình.
• Các tệp tôi tạo sẽ có cùng UID.
• Các công cụ như "ls -l" sẽ liệt kê UID là mục nhập đầu tiên trong tệp (a1 trong trường hợp này).
• Tôi tránh mọi sự cho phép hoặc quyền sở hữu giữa hai tài khoản vì chúng thực sự là cùng một người dùng.
• Tôi nhận được kiểm toán đăng nhập cho từng tài khoản, vì vậy tôi có mức độ chi tiết tốt hơn để theo dõi những gì đang xảy ra trên hệ thống.

Vì vậy, câu hỏi của tôi là:

• Là khả năng này được thiết kế hay nó chỉ là cách nó xảy ra để làm việc?
• Đây có phải là nhất quán trên các biến thể * nix?
• Đây có phải là thực hành được chấp nhận?
• Có những hậu quả không lường trước cho thực hành này?

Lưu ý, ý tưởng ở đây là sử dụng điều này cho tài khoản hệ thống chứ không phải tài khoản người dùng thông thường.

Quan điểm của tôi:

Là khả năng này được thiết kế hay nó chỉ là cách nó xảy ra để làm việc?

Nó được thiết kế. Kể từ khi tôi bắt đầu sử dụng * NIX, bạn đã có thể đặt người dùng vào các nhóm chung. Khả năng có UID giống nhau mà không gặp sự cố chỉ là kết quả dự định, giống như mọi thứ, có thể mang lại sự cố nếu quản lý không chính xác.

Đây có phải là nhất quán trên các biến thể * nix?

Tôi cũng tin như thế.

Đây có phải là thực hành được chấp nhận?

Được chấp nhận như thường được sử dụng theo cách này hay cách khác, có.

Có những hậu quả không lường trước cho thực hành này?

Ngoài kiểm toán đăng nhập, bạn không có gì khác. Trừ khi bạn muốn chính xác điều đó, để bắt đầu với.

Nó sẽ hoạt động trên tất cả các Unix? Đúng.

Nó có phải là một kỹ thuật tốt để sử dụng? Không. Có những kỹ thuật khác tốt hơn. Ví dụ, sử dụng hợp lý các nhóm unix và cấu hình "sudo" được kiểm soát chặt chẽ có thể đạt được những điều tương tự.

Tôi đã thấy chính xác một nơi mà điều này được sử dụng mà không có vấn đề. Trong FreeBSD, truyền thống là tạo một tài khoản root thứ hai được gọi là "toor" (gốc được đánh vần ngược) có / bin / sh làm vỏ mặc định. Bằng cách này, nếu shell của root bị rối, bạn vẫn có thể đăng nhập.

Tôi không thể cung cấp một câu trả lời chính tắc cho các câu hỏi của bạn, nhưng về mặt giai đoạn, công ty của tôi đã làm điều này trong nhiều năm với người dùng root và chưa bao giờ có bất kỳ vấn đề nào với nó. Chúng tôi tạo người dùng 'kroot' (UID 0) với lý do duy nhất để tồn tại là có / bin / ksh làm vỏ thay vì / bin / sh hoặc bin / bash. Tôi biết các DBA Oracle của chúng tôi làm điều gì đó tương tự với người dùng của họ, có 3 hoặc 4 tên người dùng cho mỗi lần cài đặt, tất cả đều có cùng một ID người dùng (Tôi tin rằng điều này đã được thực hiện để có các thư mục nhà riêng biệt với mỗi người dùng. Mười năm, trên Solaris và Linux. Tôi nghĩ nó hoạt động như thiết kế.

Tôi sẽ không làm điều này với một tài khoản người dùng thông thường. Như bạn đã lưu ý, sau lần đăng nhập ban đầu, mọi thứ trở về tên đầu tiên trong tệp nhật ký, vì vậy tôi nghĩ rằng hành động của một người dùng có thể bị giả mạo là hành động của người khác trong nhật ký. Đối với tài khoản hệ thống mặc dù nó hoạt động rất tốt.

Là khả năng này được thiết kế hay nó chỉ là cách nó xảy ra để làm việc?

Được thiết kế theo cách đó.

Đây có phải là nhất quán trên các biến thể * nix?

Nó nên, vâng.

Đây có phải là thực hành được chấp nhận?

Phụ thuộc vào ý của bạn. Loại điều này trả lời một vấn đề cực kỳ cụ thể (xem tài khoản root / toor). Bất cứ nơi nào khác và bạn đang yêu cầu một vấn đề ngu ngốc trong tương lai. Nếu bạn không chắc đây có phải là giải pháp phù hợp hay không, thì có lẽ là không.

Có những hậu quả không lường trước cho thực hành này?

Đó là tùy chỉnh chung để coi tên người dùng và UID là có thể hoán đổi cho nhau. Như một vài người khác đã chỉ ra, kiểm toán đăng nhập / hoạt động sẽ không chính xác. Bạn cũng sẽ muốn xem lại hành vi của bất kỳ tập lệnh / chương trình liên quan đến người dùng nào (người dùng distro của bạn, usermod, tập lệnh userdel, bất kỳ tập lệnh bảo trì định kỳ, v.v.).

Bạn đang cố gắng thực hiện điều gì với điều này sẽ không được thực hiện bằng cách thêm hai người dùng này vào một nhóm mới và cấp cho nhóm đó những quyền bạn cần?

Có những hậu quả không lường trước cho thực hành này?

Có một vấn đề tôi nhận thức được. Cron không chơi tốt với bí danh UID này. Hãy thử chạy "crontab -i" từ tập lệnh Python để cập nhật các mục cron. Sau đó chạy "crontab -e" trong shell để sửa đổi tương tự.

Lưu ý rằng bây giờ cron (vixie, tôi nghĩ) sẽ cập nhật các mục tương tự cho cả a1 và a2 (in / var / spool / cron / a1 và / var / spool / cron / a2).

Đây là hành vi được mong đợi trên tất cả các bản phân phối mà tôi đã thấy và là một mẹo phổ biến mà 'kẻ thù' sử dụng để ẩn tài khoản với quyền truy cập root.

Nó chắc chắn không phải là tiêu chuẩn (tôi chưa thấy điều này khi chơi ở bất cứ đâu), nhưng không nên có bất kỳ lý do nào mà bạn không thể sử dụng điều này trong môi trường của riêng bạn nếu bạn thấy phù hợp.

Điều duy nhất xuất hiện trong tâm trí bây giờ là điều này có thể làm cho việc kiểm toán trở nên khó khăn. Nếu bạn có hai người dùng có cùng uid / gid, tôi tin rằng bạn sẽ khó có thể tìm ra ai đã làm gì khi bạn đang phân tích nhật ký.

Chia sẻ ID nhóm chính là phổ biến, vì vậy câu hỏi thực sự xoay quanh UID .

Tôi đã làm điều này trước đây để cấp cho ai đó quyền truy cập root, mà không phải tiết lộ mật khẩu root - đã hoạt động tốt. (mặc dù sudo sẽ là một lựa chọn tốt hơn, tôi nghĩ vậy)

Điều chính tôi sẽ thận trọng là những việc như xóa một trong những người dùng - chương trình có thể bị nhầm lẫn và xóa cả người dùng, hoặc các tệp thuộc cả hai hoặc những thứ tương tự.

Trên thực tế, tôi nghĩ rằng các lập trình viên có thể Giả sử mối quan hệ 1: 1 giữa người dùng và UID, do đó rất có thể có những hậu quả không mong muốn với các chương trình khác tương tự như những gì tôi đã mô tả cho userdel.

BTW - câu hỏi / câu trả lời này được cập nhật cho hệ điều hành ngày nay.

Trích dẫn từ redhat: quản lý các bài tập Số UID và GID duy nhất , nó mô tả việc sử dụng UID và GID và cách quản lý của họ và cách các trình tạo (máy chủ ID)

phải tạo các giá trị UID và GID ngẫu nhiên và đồng thời đảm bảo rằng các bản sao không bao giờ tạo ra cùng một giá trị UID hoặc GID. Nhu cầu về số UID và GID duy nhất thậm chí có thể vượt qua các miền IdM, nếu một tổ chức có nhiều tên miền khác nhau.

Tương tự, các tiện ích cho phép truy cập vào hệ thống có thể hoạt động không thể đoán trước (cùng tham chiếu):

Nếu hai mục nhập được gán cùng một số ID, chỉ mục nhập đầu tiên được trả về trong tìm kiếm cho số đó.

Vấn đề xảy ra khi khái niệm "đầu tiên" không được xác định rõ ràng. Tùy thuộc vào dịch vụ được cài đặt, tên người dùng có thể được giữ trong hàm băm có kích thước thay đổi sẽ trả về tên người dùng khác nhau dựa trên các yếu tố không nhất quán. (Tôi biết điều này là đúng, vì đôi khi tôi đã cố gắng sử dụng 2 tên người dùng với một ID, một tên người dùng cục bộ và tên kia là tên miền mà tôi muốn ánh xạ tới UID (cuối cùng tôi đã xử lý một cách hoàn toàn khác), nhưng tôi có thể đăng nhập bằng "usera", thực hiện "ai" hoặc "id" và xem "userb" HOẶC "usera" - một cách ngẫu nhiên.

Có một giao diện để truy xuất nhiều giá trị của UID từ một nhóm (các nhóm có một GID duy nhất được thiết kế để được liên kết với nhiều UID), nhưng không có giao diện di động nào trả về danh sách tên cho một UID, vì vậy bất kỳ ai cũng mong muốn giống nhau hoặc hành vi tương tự giữa các hệ thống hoặc thậm chí các ứng dụng trên cùng một hệ thống có thể gây bất ngờ.

Trong Mặt trời (bây giờ là tiên tri) yp (trang vàng) hoặc NIS (NetworkIn informationService), cũng có nhiều tài liệu tham khảo về các yêu cầu về tính duy nhất. Các chức năng và máy chủ đặc biệt được thiết lập để phân bổ ID duy nhất trên nhiều máy chủ và tên miền (ví dụ: uid_allocd, gid_allocd - trang chủ daemons cấp phát UID và GID

Nguồn thứ ba mà người ta có thể kiểm tra là tài liệu máy chủ của Microsoft về Ánh xạ tài khoản NFS. NFS là một giao thức chia sẻ tệp unix và chúng mô tả cách duy trì quyền truy cập và quyền truy cập của tệp. Ở đó, họ viết:

• UID. Đây là một số nguyên không dấu được sử dụng bởi các hệ điều hành UNIX để xác định người dùng và phải là duy nhất trong tệp passwd.

• GID. Đây là một số nguyên không dấu được sử dụng bởi hạt nhân UNIX để xác định các nhóm và phải là duy nhất trong tệp nhóm. Trang quản lý MS-NFS

Mặc dù một số hệ điều hành có thể đã cho phép nhiều tên / UID (dẫn xuất BSD, có lẽ?), Hầu hết các hệ điều hành phụ thuộc vào điều này là duy nhất và có thể hành xử không thể đoán trước khi chúng không hoạt động.

Lưu ý - Tôi đang thêm trang này, vì một người nào đó gọi mục này là hỗ trợ cho các tiện ích hiện đại để chứa các UID / GID không độc đáo ... mà hầu hết, không.

Tôi cũng không biết liệu đó có phải là một ý tưởng tốt hay không, nhưng tôi sử dụng hành vi trên ở một vài nơi. Chủ yếu là cho các tài khoản được sử dụng để truy cập máy chủ ftp / sftp và cập nhật nội dung trang web. Nó dường như không phá vỡ bất cứ điều gì và dường như làm cho việc xử lý các quyền dễ dàng hơn sau đó sẽ có nhiều tài khoản.

Chỉ gặp phải một vấn đề (khá mơ hồ) xuất phát từ việc sử dụng nhiều tài khoản có cùng UID và nghĩ rằng tôi sẽ chia sẻ nó như một ví dụ về lý do tại sao điều này không tốt.

Trong trường hợp của tôi, một nhà cung cấp đã thiết lập máy chủ cơ sở dữ liệu Informix và máy chủ ứng dụng web trên RHEL 7. Trong quá trình thiết lập, nhiều tài khoản "root" với UID 0 đã được tạo (đừng hỏi tôi tại sao). Tức là "root", "user1" và "user2", tất cả đều có UID 0.

Máy chủ RHEL 7 sau đó đã được kết nối với miền Active Directory bằng winbind. Tại thời điểm này, máy chủ Informix DB không thể khởi động được nữa. Chạy oninitđã thất bại với một thông báo lỗi nói rằng một "Must be a DBSA to run this program".

Đây là những gì chúng tôi tìm thấy trong khi xử lý sự cố:

1. Chạy id roothoặc getent passwd 0(để giải quyết UID 0 thành tên người dùng) trên hệ thống đã tham gia Active Directory sẽ trả về ngẫu nhiên "user1" hoặc "user2" thay vì "root".

2. Informix rõ ràng đang dựa vào một so sánh chuỗi để kiểm tra xem tên người dùng văn bản của người dùng bắt đầu là "root" và sẽ thất bại.

3. Nếu không có winbind, id rootvà getent passwd 0sẽ liên tục trả về "root" như tên người dùng.

Cách khắc phục là vô hiệu hóa bộ nhớ đệm và kiên trì trong /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Sau thay đổi này, UID 0 một lần nữa giải quyết ổn định thành "root" và Informix có thể bắt đầu.

Hy vọng điều này sẽ hữu ích cho một ai đó.