Neden aynı UID ile Kullanıcılar oluşturabilirim?

UID'leri anladığım kadarıyla, Unix benzeri bir işletim sistemi tarafından her kullanıcıya atanan benzersiz bir pozitif tamsayı. Her kullanıcı UID ile sisteme tanımlanır ve kullanıcı adları genellikle yalnızca insanlar için bir arabirim olarak kullanılır.

İki kullanıcı nasıl aynı UID'ye sahip olabilir, bu sistemim ve paketlerim için bir çelişki değil mi?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

Aynı UID ve GID ile iki kullanıcıları ekledik: test12ve test13

Çıktısı /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

Kullanıcıları ekledim useradd -ou 1005 -g1000 username.

Kafam karıştı, bunun amacı nedir ve izinleri ve kullanıcı kayıtlarını vb. Etkileyebilir mi? Öyleyse, eğer bir kullanıcı eklenmişse uid=0ve gid=0bir root hesabı gibi ayrıcalıklara sahip olacaksa ?

Buradaki cevap, Linux'un sizi kendinizden korumamasıdır.

Gerçekten su root/ etc dosyalarına gidip gitmek ve tüm kullanıcılara aynı UID'yi vermek istiyorsanız, bunu yapabilirsiniz. Bu sadece bir metin dosyası.

Ama gerçekten yapmamalısın ve istenmeyen sonuçlara yol açacak.

Bunun gerçekten geçerli nedenleri var. Mesela, hepimizin kendi bilgisayarının bulunduğu bir laboratuarda çalışıyordum, ancak bizim $HOMEbir sunucu tarafından ihraç edilen paylaşılan bir sürücüdeydik. Yani, benim $HOMEoldu

/users/terdon

Yana /usersklasör benim yerel makinede aslında değildi ama, ben yük laboratuarın ağına olmamak için benim yerel sabit diskler üzerinde depolanan verileri kullanmak istiyorsunuz I / O üzerinde ağır oldu herhangi analizi için, NFS üzerinden ihraç etti. Bu amaçla ben ve diğer herkesin iki kullanıcısı vardı: biri sistem genelinde diğeri söz konusu makineye yereldi. Yerel kullanıcının evi

/home/localuser

Ancak, ben olarak oturum olup olmadığını dosyalarıma tam erişime sahip gerekiyordu terdonya da localuserher iki vererek bizim sysadmin gerçeklestirmislerdir yolu localuserve terdonaynı UID. Bu şekilde, şu anda oturum açmış olduğum kullanıcıya bakılmaksızın yerel dosyalarımı serbestçe değiştirebiliyorum.

İki kullanıcı aynı UID'ye sahip olabilir, çünkü bir metin dosyasındaki bir sayıdır, bu nedenle zaten kullanılan bir değer de dahil olmak üzere istediğiniz herhangi bir şeyi ayarlayabilirsiniz. Gördüğünüz gibi, bunu yapmak iyi bir fikir değil.

Aynı kimliğe sahip iki kullanıcıya sahip olmak aslında oldukça yaygın. FreeBSD'de, genellikle UID 0 kullanan iki kullanıcı vardır: root ve toor. Kök yerleşik / bin / sh kabuğunu kullanır ve toor genellikle bash olmak üzere farklı bir kabuk kullanır.

Unix sistemleri ve Linux genellikle /etc/passwddosyadaki kopyaları yasaklayan hiçbir şey yapmaz . Bu dosyanın amacı, bir UID'yi, lskullanıcının dosyaları listelerken olduğu gibi komut satırı araçlarıyla görüntülenebilecek bir fiziksel adla ilişkilendirmektir .

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

Bu dosyanın amaçlanan diğer amacı, bir kullanıcı oturum açtığında hangi kabuğu alacağını belirlemektir.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

Unix tipi sistemlerde yaygın bir saldırı vektörü, bir sistem /etc/passwddosyasına bunlar gibi satırlar eklemektir :

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

Rolü /etc/passwddosyası olduğu DEĞİL yalnızca kullanıcı hesaplarını izlemek için geliyordu. Kullanıcı adı ve şifreleri takip etmenin rolü /etc/shadowdosyanın sorumluluğundadır . Gibi /etc/passwdve dosyaları /etc/groupgerçekten, sisteminiz disklerden dosya listelerken insan tarafından okunabilir bir ad sağlamak içindir.

Unutmayın ki, dosyalarınız diske UID / GID değil asıl adlarını kullanarak yazılmıştır.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

Dikkat edin Uid:ve Gid:sayılar aslında diske yazılanlardır!

Linux'ta, tüm kullanıcılar ve gruplar aslında sadece sayılardır. Bu, idgönderdiğiniz komutun çıktısını gösterir.

/etc/passwdDosya kullanıcı haritalar isimleri kullanıcı için kimlikleri (sayılar) ve sahip sağlamak örnekte, sadece aynı kullanıcı kimliğine iki adlarını eşlediyseniz.

Etkili bir şekilde, test12ikinci bir kullanıcı adı da olan bir kullanıcı , ID 1005 oluşturdunuz test13. Ancak sistem, bulduğu ilk kullanıcı adına UID 1005’i eşleyecektir.test12

Linux bunu yapmanıza izin veriyor çünkü bunu yapmanıza engel olacak bir sistem yok. /etc/passwdsadece bir metin dosyasıdır, kullanıcı adları bu dosyaya girdikleri için bulunan UID ile eşleştirilir, UID'ler bu dosyada bulunan ilk kullanıcı adına eşleştirilir.

Fakat yarattığınız şey, diğer sistem yöneticileri için kafa karıştırıcı bir durum; kullanıcı kimliğini değiştirerek kaçınıntest13

Buna bugün izin verilmesinin nedeni, sistemin engellememesidir.

Bu değiştiyse, o zaman yöneticilerin bu özelliği kullandığı sistemleri bozacaktır (bkz. Terdon'un örneği). Bu yüzden hiç değişmedi ve asla olacağını sanmıyorum.

Başlangıçta yalnızca parola ve grup dosyaları vardı ve amaçlarına hizmet ediyorlardı. Orada hiçbir idi İÇİNadduser komut hayır, addgroup , dosyalar vi veya ed kullanarak root tarafından yayına hazırlanmıştır.

Birkaç tuhaflık vardı!

Kullanılacak bir sonraki kullanıcı kimliğini hatırlamak için, yöneticilerin, kullanıcı adı olan !( !geçersiz bir kullanıcı adı olduğu için) kullanıcı adı olan son satır olarak özel bir kullanıcıya sahip olması yaygındı ve bu giriş bir sonraki adı saklamak için kullanıldı. Kullanıcı kimliği. Ham, itiraf ediyorum, ama işe yaradı! Öyleyse neden bugün daha çevik bir gelişmeye benzeyen, daha karmaşık hale getiren bir bağırsaktan kurtulun.

Bilinen kusurlar vardı. Asıl varlık, dünyanın okunabilir olması gerekiyordu, böylelikle benzeri programlar lsharitalanabilirdi user-id => name. Bu, herkesin şifreli şifresini, sistemdeki tüm kullanıcıları ve kimlikleri görebileceği anlamına geliyordu.

Bazı Unix sistemleri, birkaç kabuk betiği sunmaya başladı adduser addgroup, genellikle bunlar göz ardı edildi, çünkü bunlar Unix'ler arasında tutarsızdı, bu yüzden çoğu kişi el ile düzenlemeye devam etti.

shadowŞifre dosyası icat edilmeden önce birkaç yıl sürdü , bu şifreli şifreleri gizleyerek biraz daha fazla güvenlik sağladı. Yine, sadece yeterince karmaşıklık eklendi, ama yine de oldukça kaba ve basitti. Yardımcı programları useraddve groupaddtanıtıldı, hangi tuttu shadowve shadow-güncellendi. Başlangıç ​​olarak, bunlar genellikle üreticilerin tescilli adduser / addgroup yardımcı programlarının etrafındaki basit kabuk betiği sarmalayıcılarıydı . Yine devam etmek için yeterliydi.

Bilgisayarların ağları büyüyordu, insanlar işleri yapmak için bir anda birkaç kez çalışıyorlardı, bu yüzden passwd/groupdosyaların yönetimi kabus haline geliyordu, özellikle NFS'de, bu yüzden yükü hafifletmek için NIS olarak da bilinen Sarı Sayfalar geliyor.

Artık biraz daha esnek bir şeyin gerekli olduğu ortaya çıktı ve PAM icat edildi. Eğer gerçekten karmaşık olsaydınız ve merkezileşmiş, güvenli, benzersiz bir kimlik sahibi olsaydınız, tüm ziller ve ıslık doğrulama sistemleri, kimliğinizi doğrulamak için merkezi bir sunucuya, belki de bir Radius sunucusuna, LDAP sunucusuna ya da Aktif bir dizine çağrı yapardınız.

Dünya büyümüştü. Ancak passwd / group / shadow dosyaları hala daha küçük kullanıcılar / geliştiriciler / laboratuvarlar için kaldı. Hala tüm çan ve ıslıklara ihtiyacımız olmadı. Sanırım, felsefe biraz değişti, "Eğer daha iyisini yapacak olsaydınız, hiç kullanmazdınız" , bu yüzden endişelenmeyin.

Bu yüzden basit şifre dosyasının hiçbir zaman değişmeyeceğini düşünmüyorum. Artık hiçbir anlamı yok ve 2 belki 3 kullanıcının izleme sıcaklığına ve twitter yayınlarına sahip olan £ 30 Ahududu Pi'ler için harika. Tamam, sadece onları benzersiz istiyor ve sarma gelen meraklısı önlemek için şey yoksa kullanıcı kimliği en ile biraz dikkatli olmak zorunda useradd komutunun Senaryoya hangi ilk seçer set a bir veritabanı (dosya) sonraki benzersiz kimlik benzersiz bir kimlik, eğer istediğin buysa. Sonuçta açık kaynak.

/etc/passwdDosya tıpkı gerçek kullanıcı kimliği için sembolik adlarını eşleştirir. Kasten bir kullanıcı kimliği ile eşleşen iki sembolik isim yaparsanız, o zaman size izin verecektir.

Bu, gerçekten yapmanın iyi bir fikir olduğu anlamına gelmez. Bazı insanlar bu özellikten yararlanabilecekleri çok özel kullanım durumları bulmuş olabilir, ancak genel olarak bunu yapmamalısınız.

Linux (ve diğer UNIX'ler) yöneticinin ne yaptığını bildiği görüşündedir. Aptalca bir şey yapmasını söylersen, bu senin suçun, aynı şekilde, aracına uçurumdan gitmesini söylersen üreticilere gidemezsin ve aracın neden bunu yapmana izin verdiğini sorarsın.

İşletim sisteminin benzersiz olmasını beklediği tanımlayıcıları vardır, ancak donanım izleme için kullanılırlar. Belirli bir Universally Unique IDentifier’ın sistem dosyalarını içeren bir sabit sürücüye tekabül ettiği bilgisi, donanım yapılandırması değişirse çalışmaya devam etmesine yardımcı olabilir. Microsoft bu Küresel Benzersiz Tanımlayıcıları arar ve bunları tüm Windows yazılımlarını izlemek için kullanır. İronik olarak, bu kısaltmalar kötü seçildi.

İşletim sistemi perspektifinden bakıldığında, çoğu kullanıcı ve grup tanımlayıcısı, dış arabirimini değiştirmeye bağlı olarak miktarı değiştirir. Çarpışmalara rağmen normal şekilde çalışabilir; temel olarak sistem kullanıcıları ve gruplarının ihtiyaç duyduğu şey onların varlığıdır. Kullanıcıların neye ihtiyaç duyduğunu bilemez. Bu gibi durumlarda Unix felsefesi, işletim sisteminin yöneticilerin ne yaptıklarını bildiklerini varsaymaları ve hızlı bir şekilde yapmalarına yardımcı olmaları gerektiğidir.

@ Andybalholm'un cevabını destekleyen bazı kanıtlar buldum.

Gönderen APUE , §8.15:

Herhangi bir işlem gerçek ve etkili kullanıcı kimliğini ve grup kimliğini öğrenebilir. Ancak, bazen, programı çalıştıran kullanıcının giriş adını bulmak istiyoruz. getpwuid( getuid()) ' U arayabiliriz , fakat tek bir kullanıcının her biri aynı kullanıcı kimliğine sahip birden fazla oturum açma adı varsa? ( Bir kullanıcının şifre girişinde, her giriş için farklı bir giriş kabuğu olması için aynı kullanıcı kimliğine sahip birden fazla giriş olabilir .) Sistem normalde giriş yaptığımız adı takip eder (Bölüm 6.8) ve getloginfonksiyon bir yol sağlar. Bu giriş adını almak için

....

Giriş adı verildiğinde, kullanıcıyı şifre dosyasında aramak için kullanabiliriz - örneğin giriş kabuğunu belirlemek için - kullanma getpwnam.

BTW, oturum açıldığında birinin başka bir kabuğa geçip geçmeyeceğini bilmek istiyorum.