Linux'ta varsayılan grupların ve kullanıcıların nedenleri


15

Bazı olağan Linux dağıtımlarında (sırasıyla ArchLinux ve Debian) varsayılan kullanıcı ve grup yönetimine bir göz atarak, bunun hakkında ve varsayılan kurulum ve yapılandırmanın değiştirilmesinin sonuçları hakkında iki şey merak ediyorum.

Varsayılan değeri USERGROUPS_ENABde /etc/login.defsyansıtılır ki, "evet" gibi görünüyor "Varsayılan olarak, bir grup da yeni kullanıcı için oluşturulacak" bulunabilir useraddyeni bir kullanıcı oluşturulduğunda her zaman bu yüzden, insanın, a grubu aynı adla ve yalnızca bu yeni kullanıcıyla oluşturulmuş. Bunun herhangi bir kullanımı var mı yoksa bu yalnızca bir yer tutucu mu?

Bunu yaparak kullanıcı / grup / diğerleri olarak hak yönetiminin bir kısmını kaybettiğimizi hissediyorum . Bir grubun "kullanıcıları" veya "normalleri" mi olmak istersiniz, ya da her ne demek isterseniz, kendi kullanıcılarına sahip olmak yerine her kullanıcı için varsayılan grup olur mu?

Sorumun hala Arch ve Debian'da gördüklerime dayanan ikinci kısmı: varsayılan olarak oluşturulan çok sayıda kullanıcı var (FTP, HTTP, vb.). Onlara bir faydası var mı, yoksa sadece tarihsel nedenlerle varlar mı?

Onları kaldırmayı düşünüyorum ama bunu kullanabilecek hiçbir şeyi kırmak istemiyorum, ama bunu yapan hiçbir şey görmedim ve ne yapabileceği hakkında hiçbir fikrim yok. Aynı durum, hiçbir kullanıcının ait olmadığını gördüğüm varsayılan gruplar (tty, mem, vb.) İçin de geçerlidir.


Bana biraz zaman tanıyacaksan, sana güzel bir cevap vereceğim. Ben sadece yavaş bir yazarım. 30 dakika veya daha fazla olabilir.
eyoung100

Tüm bu grupların ana noktası set-id-id programları içindir.
Barmar

2
İlk soru çok yakın bu bir .
Leiaz

@ECarterYoung: Tabii ki zamanınızı alabilir, bunun için teşekkürler!
Horgix

@Leiaz: Bunu fark ettim ama yine de "Bir gruba sahip olmak" kullanıcılara "ya da" normallere "ya da ne demek istersen ona sahip olmak yerine her kullanıcı için varsayılan grup olan" diye sormak istedim. " ve daha önce bir giriş olarak sakladı. Öncelikle StackOverflow'da yayınladım ama buraya yönlendirildim.
Horgix

Yanıtlar:


13

Kullanıcı başına gruplar

Ben de kullanıcı başına gruplarda çok fazla yarar görmüyorum. Ana kullanım durumu, bir kullanıcının dosyalarına "arkadaş" erişimine izin vermek istemesi durumunda arkadaş kullanıcının grubuna eklenmesini sağlayabilir. Karşılaştığım birkaç sistem aslında bu şekilde kullanıyor.

Ne zaman USERGROUPS_ENABiçinde /etc/login.defsayarlandığında "hayır", useraddtanımlanan gruba tüm oluşturan kullanıcılara ekler /etc/default/useraddile GROUPsahada. Çoğu dağıtımda, bu 100genellikle usersgruba karşılık gelen GID olarak ayarlanır . Bu, kullanıcıların daha genel bir yönetimine sahip olmanızı sağlar. Ardından, daha hassas kontrole ihtiyacınız varsa, bu grupları manuel olarak ekleyebilir ve bunlara mantıklı kullanıcılar ekleyebilirsiniz.

Varsayılan oluşturulan gruplar

Birçoğu tarihi nedenlerden kaynaklandı, ancak birçoğunun hala geçerli kullanımları var:

  • disk, çoğu disk sürücüsü aygıtına sahip olan gruptur
  • lp paralel bağlantı noktasına sahiptir (ve bazen bardaklardaki yönetici hakları için yapılandırılır)
  • uucp genellikle seri portlara sahiptir (USB seri portlar dahil)
  • CD sürücüsüne ayrıcalıkların bağlanması için cdrom gerekir
  • Bazı sistemler sudo hakları için çark kullanır; bazıları değil
  • vb.

Diğer gruplar arka plan komut dosyaları tarafından kullanılır. Örneğin, mançalıştırıldığında geçici dosyalar vb. Üretir; Bu süreç bazı dosyalar için man grubunu kullanır ve genellikle kendi kendini temizler.


Göre Linux Standard Base Çekirdek Şartname olsa kök, bin ve cini sadece 3 kullanıcı kesinlikle zorunludur . Mantığı diğer gruplara arkasında:

İsteğe bağlı kullanıcıları ve grupları belirtmenin amacı, uygulamalar ve dağıtımlar arasındaki ad çakışmaları olasılığını azaltmaktır.

Bu yüzden bu grupları yerinde tutmak daha iyi görünüyor. Bu var teorik bazıları için, "gizemli" şeyler değil çalışma sağa başlayabilir rağmen, kırılma olmadan bunları çıkarmak mümkün (eğer vb o grubu öldürürseniz mesela, bazı erkek sayfalar oluşturulmuyorsa). Onları orada bırakmak herhangi bir zarar vermez ve genellikle tüm Linux sistemlerinin bunlara sahip olacağı varsayılır.


1
Geçici dosyalar üreten adam hakkında daha fazla bilgiyi nerede bulabilirim? Açılan bir sayfa ile, ps aux | grep manbana adam grubu altında çalışan herhangi bir işlem göstermez ve a find -group man /da bana hiçbir şey göstermez. Adam 2.6.7.1 ile standart Archlinux kurulumunda denendi.
Horgix

6

Soru 1: Aynı Kullanıcı ve Grup için Akıl Yürütme

Merhaba, ben ecyoung'um ve sen horksun. Her gün işe gidiyoruz ve programcılar ile aynı Linux Sunucusuna giriş yapıyoruz. Bir gün, çok uzun zaman önce, sistem yöneticimiz kullanıcı oluşturma ve bakımını kendi kendine kolaylaştırmaya karar verdi, bu yüzden USERGROUPS_ENABseçeneği kapattı ve mevcut tüm kullanıcıları yeni usersgruba koydu .


Bu, tüm kullanıcılar diğer tüm kullanıcı dosyalarına erişebildiğinden, kullanıcı oluşturmayı kolaylaştırdı, ancak gördüğünüz bakımı sağlamaz. Kurumsal bir ortamda bu, Sarbanes Oxley ve Segregation of Duties gibi şeyler nedeniyle büyük bir hayır . Dosya A'yı oluşturursam, Grup Bit Kullanıcılar Grubuna ayarlanır, yani Tüm kullanıcılar en azından Dosya A'yı okuyabilir. Sys yöneticisi tembel ise, bazı durumlarda tüm kullanıcılar A dosyasını RW yapabilir. ve SoD çünkü ayrı departmanlar çok daha az okuyamamalı başka herhangi bir kişi belgesi yazabilirsiniz.


Ecyoung olarak bir belge oluşturursam Kullanıcı / Grup etkinken sadece rwx haklarına sahibim. Grubumda başka kimse olmadığından, belgemi açtıklarında uyarı içeren boş bir sayfa görüyorlar. Bu Sarbanes-Oxley ve SoD'yi zorlar. Diğer kullanıcıları davet edersem, bu kullanıcıların rw erişimine izin verilir ve bunu yaparak gördüklerinin beni veya onları ısırmak için geri gelmeyeceğini biliyorum. Diğerlerinin söylediği gibi, evde ise, bu ayrılma sizin için önemli olmayabilir. Bunu belirlerseniz, seçeneği güvenle kapatabilirsiniz ve tüm kullanıcılar usersGID değeri 100 olan bir gruba eklenir . Aşağıdaki Soru 2'ye bakın.

Varsayımsal :
BT'de ve Louis Bordro'da çalışıyor. Louis Vergi ve bordro sayfasını ana dizininde tutar, ancak ikiniz de kullanıcılar grubundasınız, böylece kullanıcılar için + r ile işaretlenmiş ve e-tablosunu bulduğu için ana dizinini açarsınız. Joe'nun ve Fred'lerin yanı sıra maaş miktarını da listeliyorsun. Sizce Joe ve Fred maaşlarını bilmenizi ister mi ??


Soru 2: 0 - 500 arası grup kimlikleri

Grup kimlikleri ve tersine 0 - 500 Kullanıcı Kimlikleri sistem hesapları ve aygıt erişimi için ayrılmıştır. Bkz Önceden Yapılandırılmış sistem grupları tablosu Standart Hesap listesi için. Lütfen bu hesapları elle kaldırmayın. Örneğin, ftp kullanıcısını kaldırmak istiyorsanız, ftp arka plan programını paket yönetim sisteminizle kaldırın. Bunu yaparsanız sistem hesabı da kaldırılır. Sistem Hizmetleri aşağıdakileri içerir ancak bunlarla sınırlı değildir:

  • CUPS Baskı Hizmeti
  • MySQL Sunucu Arka Plan Programı
  • FTP Sunucusu Arka Plan Programı
  • Apace Web Sunucusu
  • Uzaktan Bağlantılar için X Sunucu Soketi
  • ALSA Ses Sistemi Arka Plan Programı
  • DBUS Hizmeti

Başkaları da var, bu nedenle diğer okuyucular yukarıdaki Hizmet listesine eklemek veya listeden kaldırmak istiyorsa lütfen bunu yapın.


5
Güzel varsayımsal, ama başarısız. 1. Varsayılan izinler genellikle 022 olarak maskelenir, yani diğer kullanıcıların yine de okuma erişimi vardır. 2. Sysad sadece tembel değil, aynı zamanda yetersizdir, çünkü departmana göre gruplar oluşturmalı ve hesap oluşturma sırasında hepsini bir gruba atamak yerine doğru grubu atamalıdır. Ardından USERGROUPS_ENABkapalı kalmalıdır. Devre dışı bırakma USERGROUPS_ENAB! = Tüm kullanıcıları aynı gruba koyma.
muru

İlk bölüm için ses: Erişim koruması hakkında ne demek istediğinizi görüyorum ve yanılıyorsam beni düzeltin, ancak bir usersgruptaki tüm kullanıcıların gruplarda uygun hak yönetimi ile ilgili bir sorun olmamalı, bu kesinlikle aynı değildir grubun sahibine göre hakları. Dolayısıyla, açmanın tek iyi noktası, USERGROUPS_ENABdiğer kullanıcılar için sınırlı erişime sahipken dosya ve dizin oluştururken varsayılan hakları korumanıza izin verdiği için daha kolay bir bakım sağlamaktır?
Horgix

Bu doğru olurdu, ancak birçok kişi Grupları ev kullanıcılarıysa doğru şekilde yönetmez. Bunu kesin olarak doğrulayamıyorum, ancak izinlerin izin yönetimini desteklemek için seçeneği oluşturduğuna inanıyorum.
eyoung100

4

Hepimiz eski günlerde olduğu gibi varsayılan bir grubu paylaşırsak, grubu engellemek için umask'ımızı 077 olarak ayarlamamız gerekir. Varsayılan benim ise, umask'ı 027 olarak ayarlayabilirim, şimdi paylaşılan bir gruba bir dizin veya dosya ayarlarsam, bu grup okuyabilir. Modlarla da uğraşmak zorunda değilim.

Bu sadece bir örnektir, ancak genel olarak, gruplara ihtiyacınız olana kadar, açılmalarını ve yönetmelerini kolaylaştıracak şekilde devre dışı bırakmanın bir yoludur.


2

Kullanıcı başına gruplar, hem "ana dizininizde gizliliğe" sahip olmanın yanı sıra "paylaşılan klasörlerde kolay işbirliği" yapmanıza olanak tanır. Kullanıcı başına gruplar olmadan her ikisine birden sahip olabilirsiniz, ancak ikisine birden sahip olamazsınız. Ayrıntılar takip edin:

Unix, ister şirket dosya sunucusu ister 2 kullanıcılı bir bilgisayar olsun, çok kullanıcılı bir sistemdir. "Ana dizininizdeki gizlilik" birkaç şekilde gerçekleştirilebilir:

"Umask 077" dosyasını, dosyalar sizin için rw ile oluşturulacak ve başkaları için izin verilmeyecek şekilde ayarlayın. Alternatif olarak, 027 veya 022 böylece dosyalarınızın bir kısmı veya tamamı okunabilir ancak yazılamaz. Açık olan dezavantajı, paylaşılan bir klasörde işbirliği yapamamanızdır, çünkü diğerleri katı izinler nedeniyle oluşturduğunuz dosyalar üzerinde çalışamaz. Bu tür dosyalar için izinleri değiştirebilirsiniz, ancak bu "çok fazla iş" ve genellikle unutulur.

İşbirliği yapmak için "umask 7" gibi bir şey istersiniz, böylece hem siz hem de sahip olan grup oluşturduğunuz dosyaları okuyabilir ve yazabilir. Bu, paylaşılan erişime ihtiyaç duyan tüm kişilerden oluşan paylaşılan klasörler ve gruplar için mükemmeldir. Ama ana klasörünüzdeki gizliliği kaybedersiniz!

Kullanıcı başına çözüm çözümdür! Umask 7 kullanıyorsunuz, yaptığınız tüm dosyalar "sizin için rw, grup için rw" alıyor. Ana dizininizdeki dosyalar, kişisel grubunuzla "sahip olma grubu" olarak oluşturulur, böylece "grup rw" iznine rağmen bu dosyalara hiç kimse erişemez. Çünkü senden başka hiç kimse o grupta değil.

Yine de paylaşılan klasörlerde ortak çalışabilirsiniz. Paylaşılan klasördeki dosyalar sahip olan grup için "rw" alır ve sysadmin, paylaşılan klasörü (ortak çalışanlar olarak adlandırılır) oradaki dosyalar için grup sahibi olacak şekilde ayarlar. Bu, ortak çalışan tüm kullanıcıların üye olduğu bu ortak çalışanlar grubu oluşturularak yapılır. Ardından yönetici, paylaşılan klasörün grup sahipliğini "ortak çalışanlar" olarak ayarlar ve paylaşılan klasör için SETGID iznini ayarlar. SETGID açıkken, paylaşılan klasörde oluşturulan her şey, paylaşılan klasörle aynı grup sahibine (ör. "Ortak çalışanlar") sahip olur. Ve umask 7 (veya alternatif olarak 2) ile, bu gruptaki herkesin okuma + yazma erişimi olacak ve bu nedenle işbirliği yapabilecektir.


0

Başlangıçta, Unix süreçleri bir seferde bir gruba ait olabilir (eskiden chgrp(1)parola alanında saklanan grup parolasını soran bir komut vardı /etc/groups). Artı sistemler birbirine sıkı sıkıya bağlı bir grup kullanıcı tarafından kullanılmıştır. usersGruptaki herkesin olması ve sistem izinlerini grup izinleriyle paylaşması mantıklıydı . Hiçbir gerçek güvenlik bilinci, düzinelerce kullanıcının az şüphesi. Aynı makinede her şey yereldi. Bir blog veya benzeri bir şeyle paylaşım yapacak ağ yok.

Bugünün Unix sistemleri yüzlerce kullanıcıya sahiptir, güvenlik gereksinimleri daha sıkıdır ve kullanıcılar (ve süreçler) birkaç gruba ait olabilir. Her kullanıcıya (daha ipucu vermeyen) bir ev grubu verin ve paylaşım için bu gruptan uzaklaşmaya izin verin. Veya ACL'ler kullanın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.