Banyak Akun * NIX dengan UID Identik

Saya ingin tahu apakah ada perilaku standar yang diharapkan dan apakah itu dianggap praktik buruk ketika membuat lebih dari satu akun di Linux / Unix yang memiliki UID yang sama. Saya telah melakukan beberapa pengujian pada RHEL5 dengan ini dan berperilaku seperti yang saya harapkan, tapi saya tidak tahu apakah saya menggoda nasib menggunakan trik ini.

Sebagai contoh, katakanlah saya memiliki dua akun dengan ID yang sama:

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

Ini artinya:

• Saya bisa masuk ke setiap akun menggunakan kata sandi sendiri.
• File yang saya buat akan memiliki UID yang sama.
• Alat-alat seperti "ls-l" akan mencantumkan UID sebagai entri pertama dalam file (a1 dalam kasus ini).
• Saya menghindari masalah izin atau kepemilikan di antara kedua akun tersebut karena mereka benar-benar pengguna yang sama.
• Saya mendapatkan audit masuk untuk setiap akun, jadi saya memiliki rincian yang lebih baik untuk melacak apa yang terjadi pada sistem.

Jadi pertanyaan saya adalah:

• Apakah kemampuan ini dirancang atau itu hanya cara kerjanya terjadi?
• Apakah ini akan konsisten di seluruh varian * nix?
• Apakah ini praktik yang diterima?
• Adakah konsekuensi yang tidak diinginkan terhadap praktik ini?

Catatan, ide di sini adalah menggunakan ini untuk akun sistem dan bukan akun pengguna normal.

Pendapat saya:

Apakah kemampuan ini dirancang atau itu hanya cara kerjanya terjadi?

Ini dirancang. Sejak saya mulai menggunakan * NIX, Anda dapat menempatkan pengguna di grup umum. Kemampuan untuk membuat UID tetap sama tanpa masalah hanyalah hasil yang dimaksudkan bahwa, seperti semuanya, dapat membawa masalah jika dikelola secara tidak benar.

Apakah ini akan konsisten di seluruh varian * nix?

Saya percaya begitu.

Apakah ini praktik yang diterima?

Diterima seperti pada umumnya digunakan dalam satu atau lain cara, ya.

Adakah konsekuensi yang tidak diinginkan terhadap praktik ini?

Selain audit masuk, Anda tidak punya apa-apa lagi. Kecuali Anda menginginkan hal itu, mulailah dengan.

Apakah ini akan berfungsi pada semua Unix? Iya.

Apakah ini teknik yang baik untuk digunakan? Tidak. Ada teknik lain yang lebih baik. Sebagai contoh, penggunaan yang tepat dari grup unix dan konfigurasi "sudo" yang dikontrol secara ketat dapat mencapai hal yang sama.

Saya telah melihat persis satu tempat di mana ini digunakan tanpa masalah. Dalam FreeBSD adalah tradisional untuk membuat akun root kedua yang disebut "toor" (root dieja mundur) yang memiliki / bin / sh sebagai shell default. Dengan cara ini jika shell root kacau Anda masih bisa login.

Saya tidak dapat memberikan jawaban kanonik untuk pertanyaan Anda, tetapi secara anekdot perusahaan saya telah melakukan ini selama bertahun-tahun dengan pengguna root dan tidak pernah memiliki masalah dengan itu. Kami membuat pengguna 'kroot' (UID 0) yang satu-satunya alasan keberadaannya adalah memiliki / bin / ksh sebagai shell alih-alih / bin / sh atau bin / bash. Saya tahu Oracle DBAs kami melakukan sesuatu yang mirip dengan penggunanya, memiliki 3 atau 4 nama pengguna per instal, semua dengan ID pengguna yang sama (Saya percaya ini dilakukan untuk memiliki direktori home yang terpisah dengan masing-masing pengguna. Kami telah melakukan ini setidaknya untuk sepuluh tahun, di Solaris dan Linux. Saya pikir ini berfungsi seperti yang dirancang.

Saya tidak akan melakukan ini dengan akun pengguna biasa. Seperti yang Anda catat, setelah login awal semuanya kembali ke nama depan dalam file log, jadi saya pikir tindakan satu pengguna dapat disamarkan sebagai tindakan yang lain di log. Untuk akun sistem meskipun berfungsi dengan baik.

Apakah kemampuan ini dirancang atau itu hanya cara kerjanya terjadi?

Didesain seperti itu.

Apakah ini akan konsisten di seluruh varian * nix?

Seharusnya begitu.

Apakah ini praktik yang diterima?

Tergantung apa yang Anda maksud. Jenis hal ini menjawab masalah yang sangat spesifik (lihat akun root / toor). Di tempat lain dan Anda meminta masalah bodoh di masa depan. Jika Anda tidak yakin apakah ini solusi yang tepat, mungkin itu bukan.

Adakah konsekuensi yang tidak diinginkan terhadap praktik ini?

Sudah menjadi kebiasaan umum untuk memperlakukan nama pengguna dan UID sebagai yang dapat dipertukarkan. Seperti yang ditunjukkan beberapa orang lainnya, audit masuk / aktivitas akan tidak akurat. Anda juga ingin meninjau perilaku skrip / program terkait pengguna yang relevan (useradd distro Anda, usermod, skrip userdel, skrip pemeliharaan berkala, dll.).

Apa yang Anda coba selesaikan dengan hal ini yang tidak akan dicapai dengan menambahkan dua pengguna ini ke grup baru dan memberikan grup itu izin yang Anda butuhkan?

Adakah konsekuensi yang tidak diinginkan terhadap praktik ini?

Ada satu masalah yang saya ketahui. Cron tidak cocok dengan aliasing UID ini. Coba jalankan "crontab -i" dari skrip Python untuk memperbarui entri cron. Kemudian jalankan "crontab -e" di shell untuk memodifikasi yang sama.

Perhatikan bahwa sekarang cron (vixie, saya pikir) akan memperbarui entri yang sama untuk a1 dan a2 (di / var / spool / cron / a1 dan / var / spool / cron / a2).

Ini adalah perilaku yang diharapkan pada semua distribusi yang saya lihat, dan merupakan trik umum yang digunakan 'musuh' untuk menyembunyikan akun dengan akses root.

Ini tentu saja bukan standar (saya belum melihat ini dalam permainan di mana pun), tetapi seharusnya tidak ada alasan bahwa Anda tidak dapat menggunakan ini di lingkungan Anda sendiri jika Anda mau.

Satu-satunya Gotcha yang terlintas dalam pikiran saat ini adalah bahwa hal ini dapat mempersulit audit. Jika Anda memiliki dua pengguna dengan uid / gid yang sama, saya yakin Anda akan kesulitan menentukan mana yang melakukan apa ketika Anda menganalisis log.

Berbagi ID grup utama adalah umum, jadi pertanyaannya benar-benar berkisar pada UID .

Saya telah melakukan ini sebelumnya untuk memberikan akses root kepada seseorang, tanpa harus membocorkan password root - yang telah bekerja dengan baik. (meskipun sudo akan menjadi pilihan yang lebih baik, saya pikir)

Hal utama yang saya harus berhati-hati adalah hal-hal seperti menghapus salah satu pengguna - program mungkin menjadi bingung dan menghapus kedua pengguna, atau file milik keduanya, atau hal-hal serupa.

Bahkan, saya berpikir bahwa programmer mungkin berasumsi hubungan 1: 1 antara pengguna dan UID, jadi ada kemungkinan konsekuensi yang tidak terduga dengan program lain yang mirip dengan apa yang saya jelaskan untuk userdel.

BTW - pertanyaan / jawaban ini diperbarui untuk OS hari ini.

Mengutip dari redhat: mengelola penugasan UID dan GID Number yang unik , ini menggambarkan penggunaan UID dan GID serta manajemennya dan bagaimana generator (server ID)

harus menghasilkan nilai UID dan GID acak dan secara bersamaan memastikan bahwa replika tidak pernah menghasilkan nilai UID atau GID yang sama. Kebutuhan untuk nomor UID dan GID yang unik bahkan mungkin melintasi domain IdM, jika satu organisasi memiliki beberapa domain yang berbeda.

Demikian pula, utilitas yang memungkinkan akses ke sistem dapat berperilaku tak terduga (referensi yang sama):

Jika dua entri diberikan nomor ID yang sama, hanya entri pertama yang dikembalikan dalam pencarian untuk nomor itu.

Masalahnya muncul ketika konsep "pertama" tidak jelas. Bergantung pada layanan yang diinstal, nama pengguna dapat disimpan dalam hash berukuran variabel yang akan mengembalikan nama pengguna yang berbeda berdasarkan faktor yang tidak konsisten. (Saya tahu ini benar, karena saya kadang-kadang mencoba menggunakan 2 nama pengguna dengan satu ID, satu menjadi nama pengguna lokal, dan yang lainnya menjadi domain.username yang ingin saya petakan ke UID (yang akhirnya saya bahas di cara yang berbeda), tetapi saya bisa masuk dengan "usera", melakukan "siapa" atau "id" dan melihat "userb" ATAU "usera" - secara acak.

Ada antarmuka untuk mengambil beberapa nilai UID dari grup (grup dengan GID tunggal dirancang untuk dikaitkan dengan beberapa UID), tetapi tidak ada antarmuka portabel untuk mengembalikan daftar nama untuk satu UID, jadi siapa pun yang mengharapkan yang sama atau perilaku serupa antara sistem atau bahkan aplikasi pada sistem yang sama mungkin terkejut.

Di Sun (sekarang oracle) yp (yellowpages) atau NIS (NetworkInformationServices), ada juga banyak referensi untuk persyaratan keunikan. Berbagai fungsi dan server khusus disiapkan untuk mengalokasikan ID unik di beberapa server dan domain (contohnya adalah uid_allocd, gid_allocd - UID dan GID daemon alokasi daemon manpage

Sumber ketiga yang mungkin diperiksa adalah dokumentasi server Microsoft untuk Pemetaan Akun NFS. NFS adalah protokol berbagi file unix dan mereka menggambarkan bagaimana izin dan akses file dikelola oleh ID. Di sana, mereka menulis:

• UID. Ini adalah bilangan bulat yang tidak ditandatangani yang digunakan oleh sistem operasi UNIX untuk mengidentifikasi pengguna dan harus unik dalam file passwd.

• GID. Ini adalah bilangan bulat yang tidak ditandatangani yang digunakan oleh kernel UNIX untuk mengidentifikasi grup dan harus unik dalam file grup. Halaman manajemen MS-NFS

Sementara beberapa OS mungkin telah mengizinkan beberapa nama / UID (turunan BSD, mungkin?) Sebagian besar OS bergantung pada ini menjadi unik dan mungkin berperilaku tidak terduga ketika mereka tidak.

Catatan - Saya menambahkan halaman ini, karena seseorang menyebut entri bertanggal ini sebagai dukungan untuk utilitas modern untuk mengakomodasi UID / GID yang tidak unik ... yang kebanyakan, tidak.

Saya juga tidak tahu apakah itu ide yang bagus atau tidak, tetapi saya menggunakan perilaku di atas di beberapa tempat. Sebagian besar untuk akun yang digunakan untuk mengakses server ftp / sftp dan memperbarui konten situs web. Tampaknya tidak merusak apa pun dan tampaknya membuat penanganan izin lebih mudah daripada dengan beberapa akun.

Hanya mengalami masalah (agak tidak jelas) yang berasal dari penggunaan beberapa akun dengan UID yang sama, dan berpikir saya akan membagikannya sebagai contoh mengapa ini bukan praktik yang baik.

Dalam kasus saya, vendor menyiapkan server basis data Informix dan server aplikasi web di RHEL 7. Selama penyiapan, beberapa akun "root" dengan UID 0 dibuat (jangan tanya kenapa). Yaitu, "root", "user1" dan "user2", semuanya memiliki UID 0.

Server RHEL 7 kemudian bergabung dengan domain Direktori Aktif menggunakan winbind. Pada titik ini, server Informix DB tidak lagi dapat memulai. Menjalankan oninitgagal dengan pesan kesalahan yang mengatakan itu "Must be a DBSA to run this program".

Inilah yang kami temukan saat pemecahan masalah:

1. Menjalankan id rootatau getent passwd 0(untuk menyelesaikan UID 0 menjadi nama pengguna) pada sistem Active Directory bergabung akan secara acak mengembalikan "user1" atau "user2" bukannya "root".

2. Informix tampaknya mengandalkan perbandingan string untuk memeriksa apakah nama pengguna tekstual dari pengguna yang memulai itu adalah "root" dan akan gagal sebaliknya.

3. Tanpa winbind, id rootdan getent passwd 0secara konsisten akan mengembalikan "root" sebagai nama pengguna.

Cara mengatasinya adalah menonaktifkan caching dan kegigihan di /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Setelah perubahan ini, UID 0 sekali lagi secara konsisten diselesaikan ke "root" dan Informix dapat memulai.

Semoga ini bermanfaat bagi seseorang.