Aynı UID'ye sahip Birden Çok * NIX Hesabı

Beklenen standart bir davranış olup olmadığını ve Linux / Unix'te aynı UID'ye sahip birden fazla hesap oluştururken kötü uygulama olup olmadığını merak ediyorum. RHEL5 üzerinde bu konuda bazı testler yaptım ve beklediğim gibi davrandı, ama bu hileyi kullanarak kaderi cazip hale getirip getirmediğimi bilmiyorum.

Örnek olarak, aynı kimliğe sahip iki hesabım olduğunu varsayalım:

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

Bunun anlamı:

• Her hesaba kendi şifresini kullanarak giriş yapabilirim.
• Oluşturduğum dosyalar aynı UID'ye sahip olacak.
• "Ls -l" gibi araçlar, UID'yi dosyadaki ilk giriş olarak listeler (bu durumda a1).
• Gerçekten aynı kullanıcı oldukları için iki hesap arasında izin veya sahiplik sorunlarından kaçınıyorum.
• Her hesap için giriş denetimi alıyorum, bu yüzden sistemde neler olduğunu izleme konusunda daha iyi ayrıntı düzeyine sahibim.

Yani sorularım:

• Bu yetenek tasarlandı mı, yoksa sadece çalışma şekli mi?
• Bu, * nix varyantlarında tutarlı mı olacak?
• Bu kabul edilmiş bir uygulama mı?
• Bu uygulamanın istenmeyen sonuçları var mı?

Burada dikkat edilmesi gereken nokta, bunu normal kullanıcı hesapları için değil sistem hesapları için kullanmaktır.

Benim fikrim:

Bu yetenek tasarlandı mı, yoksa sadece çalışma şekli mi?

Tasarlanmıştır. * NIX kullanmaya başladığımdan beri, kullanıcıları ortak gruplara yerleştirebildiniz. UID'nin sorunsuz bir şekilde aynı olması, her şey gibi, yanlış yönetilirse sorun yaratabilecek amaçlanan bir sonuçtur.

Bu, * nix varyantlarında tutarlı mı olacak?

Öyle inanıyorum.

Bu kabul edilmiş bir uygulama mı?

Genellikle bir şekilde kullanıldığı gibi kabul edilir, evet.

Bu uygulamanın istenmeyen sonuçları var mı?

Giriş denetimi dışında başka hiçbir şeyiniz yoktur. Tam olarak bunu istemedikçe, başlamak için.

Tüm Unix'lerde çalışır mı? Evet.

Kullanmak iyi bir teknik midir? Hayır. Daha iyi başka teknikler de var. Örneğin, unix gruplarının ve sıkı denetimli "sudo" konfigürasyonlarının uygun kullanımı aynı şeyleri başarabilir.

Bunun sorunsuz bir şekilde kullanıldığı bir yer gördüm. FreeBSD'de, varsayılan kabuk olarak / bin / sh değerine sahip "toor" (kök geriye doğru yazılır) adı verilen ikinci bir kök hesap oluşturmak gelenekseldir. Bu şekilde root'un kabuğu bozulursa yine de giriş yapabilirsiniz.

Sorularınıza kanonik bir cevap veremiyorum, ama anekdot olarak şirketim bunu kök kullanıcıyla yıllardır yapıyor ve onunla hiç bir sorun yaşamadım. Tek varoluş nedeni / bin / sh veya bin / bash yerine kabuk olarak / bin / ksh olmak olan bir 'kroot' kullanıcısı (UID 0) oluşturuyoruz. Oracle DBA'larımızın kullanıcılarına benzer bir şey yaptığını biliyorum, kurulum başına 3 veya 4 kullanıcı adına sahip, hepsi aynı kullanıcı kimliğine sahip (bunun her kullanıcı ile ayrı ev dizinleri olması için yapıldığına inanıyorum.) Solaris ve Linux'ta on yıl, sanırım tasarlandığı gibi çalışıyor.

Bunu normal bir kullanıcı hesabıyla yapmam. Belirttiğiniz gibi, ilk girişten sonra her şey günlük dosyasında ilk isme geri döner, bu yüzden bir kullanıcının eylemlerinin günlüklerde başka birinin eylemleri olarak maskelenebileceğini düşünüyorum. Sistem hesapları için harika çalışıyor olsa da.

Bu yetenek tasarlandı mı, yoksa sadece çalışma şekli mi?

Bu şekilde tasarlandı.

Bu, * nix varyantlarında tutarlı mı olacak?

Olmalı, evet.

Bu kabul edilmiş bir uygulama mı?

Ne demek istediğine bağlı. Bu tür şeyler son derece spesifik bir soruna cevap verir (bkz. Root / toor hesapları). Başka bir yerde ve gelecekte aptalca bir sorun istiyorsunuz. Bunun doğru çözüm olup olmadığından emin değilseniz, muhtemelen değil.

Bu uygulamanın istenmeyen sonuçları var mı?

Kullanıcı adlarını ve UID'leri değiştirilebilir olarak ele almak genel bir gelenektir. Diğer birkaç kişinin işaret ettiği gibi, giriş / etkinlik denetimleri yanlış olacaktır. Ayrıca, kullanıcıyla ilgili herhangi bir komut dosyasının / programın (dağıtımınızın kullanıcı kodu, usermod, kullanıcı dosyası komut dosyaları, periyodik bakım komut dosyaları vb.) Davranışlarını da incelemek istersiniz.

Bu iki kullanıcıyı yeni bir gruba ekleyerek ve bu gruba ihtiyacınız olan izinleri vererek gerçekleştirilemeyecek olan, bununla ne yapmaya çalışıyorsunuz?

Bu uygulamanın istenmeyen sonuçları var mı?

Farkında olduğum bir konu var. Cron bu UID takma adıyla iyi oynamıyor. Cron girdilerini güncellemek için bir Python betiğinden "crontab -i" komutunu çalıştırmayı deneyin. Sonra aynı değiştirmek için kabuk "crontab -e" çalıştırın.

Şimdi cron (vixie, sanırım) hem a1 hem de a2 için aynı girişleri güncelleyeceğine dikkat edin (/ var / spool / cron / a1 ve / var / spool / cron / a2).

Bu, gördüğüm tüm dağıtımlarda beklenen davranıştır ve 'düşmanın' kök erişimi olan hesapları gizlemek için kullandığı yaygın bir numaradır.

Kesinlikle standart değil (Bunu hiçbir yerde oyunda görmedim), ancak uygun görürseniz bunu kendi ortamınızda kullanamamanız için herhangi bir neden olmamalıdır.

Şu anda akla gelen tek şey, bunun denetimi zorlaştırabileceğidir. Aynı uid / gid ile iki kullanıcınız varsa, günlükleri analiz ederken hangisinin ne yaptığını anlamakta zorlanacağınıza inanıyorum.

Etrafında soru gerçekten döndürülür böylece böylece birincil grup kimlikleri paylaşan yaygındır UID .

Bunu daha önce işe yaramış olan root şifresini açıklamak zorunda kalmadan birine root erişimi vermek için yaptım. (sudo daha iyi bir seçim olsa da, bence)

Programı - Ben dikkatli olacağını Önemli olan kullanıcıların birini silme gibi şeyler olabilir karıştı ve her iki kullanıcıları silmek veya dosyalar hem ait veya benzer şeyler.

Aslında, programcıların muhtemelen kullanıcı ve UID arasında 1: 1 ilişki olduğunu varsayalım , bu yüzden userdel için tarif ettiğim gibi diğer programlarla beklenmedik sonuçlar olabilir.

BTW - bu soru / cevap bugünün işletim sistemleri için güncellendi.

Redhat'tan alıntı : benzersiz UID ve GID Numarası atamalarını yönetmek , UID ve GID'lerin kullanımını ve yönetimini ve üreticilerin (ID sunucuları) nasıl olduğunu açıklar

rastgele UID ve GID değerleri üretmeli ve eşzamanlı olarak eşlemelerin asla aynı UID veya GID değerini üretmemesini sağlamalıdır. Tek bir kuruluşta birden fazla farklı alan varsa, benzersiz UID ve GID numaralarına duyulan ihtiyaç IdM alan adlarını bile aşabilir.

Benzer şekilde, sisteme erişime izin veren yardımcı programlar beklenmedik şekilde davranabilir (aynı başvuru):

İki girişe aynı kimlik numarası atanırsa, bu numara için yapılan aramada yalnızca ilk giriş döndürülür.

Sorun, "ilk" kavramı kötü tanımlandığında ortaya çıkar. Yüklenen hizmete bağlı olarak, kullanıcı adları, tutarsız faktörlere dayalı olarak farklı bir kullanıcı adı döndürecek değişken boyutlu bir karmada tutulabilir. (Biri yerel kullanıcı adı, diğeri UID ile eşlemek istediğim bir domain.username olmak üzere bazen bir kimlikle 2 kullanıcı adı kullanmaya çalıştığımdan bunun doğru olduğunu biliyorum (sonunda ele aldım) tamamen farklı bir yol), ancak "usera" ile giriş yapabilir, "kim" veya "id" yapabilir ve "userb" VEYA "usera" görebilirsiniz - rastgele.

Bir gruptan birden fazla UID değeri almak için bir arabirim vardır (tek bir GID'ye sahip gruplar, birden çok UID ile ilişkilendirilmek üzere tasarlanmıştır), ancak bir UID için ad listesini döndürmek için taşınabilir bir arabirim yoktur, bu nedenle aynı olan herkes veya sistemler arasındaki benzer davranışlar ve hatta aynı sistemdeki uygulamalar bile mutsuz bir şekilde şaşırtabilir.

Güneş'te (şimdi oracle) yp (sarı sayfalar) veya NIS'de (NetworkInformationServices), benzersizlik gereksinimlerine birçok referans da vardır. Özel işlevler ve sunucular, birden fazla sunucu ve etki alanına benzersiz kimlikler ayıracak şekilde ayarlanmıştır (örnek, uid_allocd, gid_allocd - UID ve GID ayırıcı artalan programı cinleri kılavuzudur

Kontrol edilebilecek üçüncü bir kaynak, Microsoft'un NFS Hesap Eşlemesi ile ilgili sunucu belgeleridir. NFS bir unix dosya paylaşım protokolüdür ve dosya izinlerinin ve erişiminin kimlik tarafından nasıl korunduğunu açıklar. Orada yazıyorlar:

• UID. Bu, UNIX işletim sistemleri tarafından kullanıcıları tanımlamak için kullanılan imzasız bir tamsayıdır ve passwd dosyasında benzersiz olmalıdır.

• GID. Bu, grupları tanımlamak için UNIX çekirdeği tarafından kullanılan işaretsiz bir tam sayıdır ve grup dosyasında benzersiz olmalıdır. MS-NFS yönetim sayfası

Bazı işletim sistemleri birden fazla isme / UID'ye (BSD türevleri, belki de?) İzin vermiş olsa da, çoğu işletim sistemi bunun benzersiz olmasına bağlıdır ve olmadığında tahmin edilemez şekilde davranabilir.

Not - Birisi bu tarihli girişe benzersiz olmayan UID / GID'leri karşılamak için modern araçlar için destek olarak bahsettiğim gibi ekliyorum ...

Bunun iyi bir fikir olup olmadığını da bilmiyorum, ancak yukarıdaki davranışı birkaç yerde kullanıyorum. Çoğunlukla ftp / sftp sunucusuna erişmek ve web sitesi içeriğini güncellemek için kullanılan hesaplar içindir. Hiçbir şey kırmamış gibi görünmüyordu ve izinlerin işlenmesini daha kolay hale getirmiş gibi görünüyordu.

Sadece aynı UID ile birden fazla hesabın kullanılmasından kaynaklanan (oldukça belirsiz) bir sorunla karşılaştım ve bunun neden iyi bir uygulama olmadığının bir örneği olarak paylaşacağımı düşündüm.

Benim durumumda, bir satıcı RHEL 7 üzerinde bir Informix veritabanı sunucusu ve bir web uygulama sunucusu kurdu. Kurulum sırasında, UID 0 ile birden fazla "kök" hesap oluşturuldu (nedenini sorma). Yani, "root", "user1" ve "user2", hepsi UID 0'a sahiptir.

RHEL 7 sunucusu daha sonra winbind kullanılarak bir Active Directory etki alanına katıldı. Bu noktada, Informix DB sunucusu başlatılamadı. Koşu oninit, bunu söyleyen bir hata mesajı ile başarısız oldu "Must be a DBSA to run this program".

Sorun giderme sırasında bulduklarımız:

1. Koşu id rootveya getent passwd 0Active Directory (bir kullanıcı adı içine çözmek UID 0) sistemi rastgele "Kullanıcı1" ya da bunun yerine "root" nin "kullanıcı2" ya dönecekti katıldı.

2. Informix, onu başlatan kullanıcının metin kullanıcı adının "kök" olup olmadığını ve aksi takdirde başarısız olup olmadığını kontrol etmek için bir dize karşılaştırmasına güveniyordu.

3. Winbind olmadan id rootve getent passwd 0sürekli kullanıcı adı olarak "root" dönecekti.

Düzeltme, önbellekleme ve kalıcılığı devre dışı bırakmaktı /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Bu değişiklikten sonra, UID 0 bir kez daha tutarlı bir şekilde "root" a çözümlendi ve Informix başlatılabilir.

Umarım bu birisi için yararlı olur.