Soru Apache 2'nin www / data / var / www kullanıcı izinlerini ele almanın en iyi yolu nedir?


İçerisinde dosyaları işlemek için güzel bir çözüm var mı /var/www? Ad Tabanlı Sanal Sunucuları çalıştırıyoruz ve Apache 2 kullanıcısı www veri.

İki düzenli kullanıcımız var. Bu yüzden, dosyalar /var/wwwyerine sahip olmaktan ...

chown -R www-data:www-data

... her zaman, bunun için iyi bir yol nedir?

Tamamlayıcı soru: Ne kadar sert izinler veriyorsunuz?

Bu, işbirliğine dayalı geliştirme ortamlarında her zaman bir sorun olmuştur.


211
2018-05-11 05:13


Menşei


Ayrıca bakınız: Web sitem için kullanılacak en iyi linux izinleri nelerdir? - Zoredache


Cevaplar:


@ Zoredache'nin üzerinde genişletmeye çalışılıyor Cevap, bunu verdiğim gibi kendim gidin:

  • Yeni bir grup (www-pub) oluşturun ve kullanıcıları bu gruba ekleyin

    groupadd www-pub

    usermod -a -G www-pub usera  ## mevcut gruplara eklemek için -a kullanmalıdır

    usermod -a -G www-pub userb

    groups usera  kullanıcı için ## ekran grupları

  • / Var / www altındaki her şeyin sahipliğini root olarak değiştirin: www-pub

    chown -R root:www-pub /var/www  Yinelemek için ## -R

  • Tüm klasörlerin izinlerini 2775 olarak değiştirin

    chmod 2775 /var/www  ## 2 = set grubu kimliği, 7 = sahip olmak için rwx (root), 7 = grup için rwx (www-pub), dünya için 5 = rx (apache www-data kullanıcısı dahil)

    Grup kimliğini ayarlasetgid) bit (2), grubun (www-pub) bu ​​klasörde oluşturulan tüm yeni dosyalara / klasörlere kopyalanmasını sağlar. Diğer seçenekler SETUID (4) kullanıcı kimliğini kopyalamak içindir ve STICKY (1) sadece sahibin dosyaları silebilmesini sağlar.

    Orada bir -R özyinelemeli seçenek, ancak bu dosyalar ve klasörler arasında ayrım yapmaz, yani bulmak bulmak, böyle:

    find /var/www -type d -exec chmod 2775 {} +

  • Tüm dosyaları 0664 olarak değiştirin

    find /var/www -type f -exec chmod 0664 {} +

  • Kullanıcılarınızın umask değerini 0002 olarak değiştirin

    Umask, varsayılan dosya oluşturma izinlerini kontrol eder, 0002, dosyaların 664 ve dizinlerin 775 olacağı anlamına gelir. umask altındaki çizgi /etc/profile Benim durumumda), bir kullanıcının yarattığı dosyaların, www grubundaki diğer kullanıcılar tarafından yazılmaya gerek olmadan yazılabileceği anlamına gelir chmod onlar.

Tüm bunları bir dosya ve dizin oluşturarak ve sahip, grup ve izinlerle doğrulayarak sınayın. ls -l.

Not: Etkili olması için gruplarınızdaki değişiklikler için çıkış yapmalısınız.


201
2017-09-15 05:11



@Tom Kullanmayı önerdiğini görmek için harika findBunun için komut. Çok sayıda dosya / dizininiz varsa ve GNU bulgusunu kullanıyor iseniz vereceğiniz küçük bir performans ipucu kullanmaktır. + yerine \; böylece komut birden fazla dosya üzerinde çalış Çünkü "Dosya başına bir defada bir defada mümkün olduğunca çok dosya üzerinde bir komut çalıştırmak daha hızlıdır. Bunu yapmak, her seferinde komutu başlatmak için gereken süreden tasarruf sağlar." Ayrıca, ters eğikliğe ihtiyaç duymadığı için yazmak daha kolaydır. - aculich
@ Aculich'in önerisini + kullanma \ ile güncellendi \; - Tom
@SunnyJ. Bunu deneyin (dış tırnak olmadan): "bul / var / www -type f -exec chmod 0664 '{}' + +" Bunu deneyin. '{}' Ve \ + arasında boşluk var. - Buttle Butkus
@ Kırpmak için Tom yolu, teşekkürler. Sadece bir not - Bence "SETUID (4) kullanıcı kimliğini kopyalamak için" cevabınıza dahil olarak yanlıştır - Linux / Unix dizinlerine uygulandığında SETUID göz ardı edilir - Ref - Yarin
Tamam, yani usera ve userb demek istiyorsun www-data ve ftpuser ? Bunu çok kafa karıştırıcı buldum. www-data, asıl sorudaydı. Ayrıca, sahibinin ayarlanması için nokta / fayda nedir? root? Bunu ayarlamalı mıyız? ftpuser? - gskema


İzinleri nasıl yapılandırmak istediğinizden emin değilim, ancak bu size bir başlangıç ​​noktası verebilir. Muhtemelen daha iyi yollar vardır. Her iki kullanıcının da / var / www / altındaki herhangi bir şeyi değiştirmesini isteyebilirsiniz.

  • Yeni bir grup (www-pub) oluşturun ve kullanıcıları bu gruba ekleyin.
  • / Var / www altındaki her şeyin mülkiyetini root: www-pub olarak değiştirin.
  • Tüm klasörlerin izinlerini 2775 olarak değiştirin
  • Tüm dosyaları 0664 olarak değiştirin.
  • Kullanıcılarınızın umask değerini 0002 olarak değiştirin

Bu, kullanıcılarınızdan birinin oluşturduğu herhangi bir yeni dosyanın kullanıcı adı olması gerektiği anlamına gelir: www-pub 0664 ve oluşturulan herhangi bir dizin kullanıcı adı olacaktır: www-pub 2775. Apache, 'diğer kullanıcılar' bileşeni üzerinden her şeye erişimi okuyacaktır. Dizinlerdeki SETGID biti, oluşturulmakta olan tüm dosyaların, klasörün sahibi olan gruba ait olmaya zorlayacaktır. Yazım bitinin, gruptaki herkesin dosyaları düzenleyebilmesi için ayarlandığından emin olmak için umask ayarının yapılması gerekir.

Ne kadar sert olduğu konusunda izinlerim var. Bu tamamen site / sunucuya bağlıdır. Eğer sadece 1-2 editör varsa ve onları çok kötü bir şeyden kırmaya ihtiyacım varsa, o zaman ben kolay giderim. Eğer iş daha karmaşık bir şey gerektiriyorsa, daha karmaşık bir şey kurardım.


59
2018-05-11 05:49



Web sunucusu tarafından www-data ve www. - gacrux
'Diğer' izinlere güvenmek yerine kullanıcıları apache grubuna eklemek de işe yarayacak mı? Tüm yaptığınız dosyalar dosya yüklüyorsa ve bu dosyaların apache tarafından okunması gerekiyorsa, bu dosyaları düzenlemeniz gerekiyorsa sadece 3. grup yararlı görünmektedir. - Simurr
Bu biraz daha genişletme şansı @Zoredache? Rwx bitleri, chmod, chown, adduser, usermod'ların temel kullanımını biliyorum, fakat beni sekizlik izinler, umasklar ve tüm bunlar üzerindeki ekstra ilk rakamla kaybettiniz. Özetlenen yaklaşımınızı gösteren bazı örnek komutlar büyük ölçüde takdir edilecektir. - Tom
Bu şekilde her kullanıcı diğer kullanıcı dosyalarına erişebilir! Bu, userA'nın userB ... mysql kimlik bilgilerini saklamak için config.php okuduğunu gösterir. - drAlberT
Acl kullanarak hem güvenliği hem de işbirliğini ele alabilirsiniz :) - drAlberT


Bence yardımcı olmak için POSIX ACL (erişim kontrol listeleri) bulabilirsin. Kullanıcıya göre daha ince bir izin modeline izin verirler: grup: diğer model. Daha açık olabileceğinden ve dosya sisteminin bir dalı için "varsayılan" davranışı ayarlayabildiğinden, onları doğrudan kafamda tutmanın daha kolay olduğunu buldum.

Örneğin, her bir kullanıcının izinlerini açıkça belirtebilirsiniz:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Ya da bazı paylaşılan gruplara göre yapabilirsiniz:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

Ve belki de Apache kullanıcınızı salt okunur olarak tutmak istersiniz.

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Man sayfaları:

Eğitimi


39
2018-05-11 16:26



budur yol ! +1 - drAlberT
Kazanmak için ACL +1 ... Daha fazla bilgi için serverfault.com/a/360120/41823 - Yarin
ACL ve temel izinler için herhangi bir performans düşüşü olup olmadığını merak ediyorum. - Buttle Butkus
Ne yazık ki, ACL standart kurulumlarda / dağıtımlarda çok eksiktir. Kimi zaman yönetdiğim ya da daha kötüsü, dosya sistemini değiştirdiğim her sunucuda çekirdek derlemek bir acıdır. Ayrıca, özellikle sunucu değiştiriyorsanız, dosyaları yedeklerken çok dikkatli olmalısınız. ACL harika ama şu anki desteği o kadar düşük ki, sunucu ve çevre üzerindeki her şey üzerinde tam kontrole sahip olmayan herkese karşı tavsiye ederim. Ama ACL'yi işaret etmek için +1 gerçekten anlamlı olduğu yerde! - Ninj
İyi cevap +1; Apache sürecinin okuma / yazma izinlerini değiştirmeyle ilgili bir not (www-data Örneğin, tüm sitenin salt okunur olması (setfacl veya chmod yoluyla - veya her ikisi de) -> Bu, tüm yazımları (örneğin, çoğu CMS'de tarayıcı tarafındaki eklenti / modül yükleme / güncelleme) açıkça engelleyecektir. Pek çok popüler kişinin sadece grup seviyesinde değil, kullanıcı izin seviyesinde yazma erişimi için test ettiğine inanıyorum. Güncellemeye devam edebilirsiniz, ancak güncellemeler manuel olarak ve yazma klasörleri için herhangi bir özel izin (logs / temp / uploads / etc) uygulanmalıdır. Sitenizde çalışıyorsa, salt okunurluk, büyük güvenliktir. - bshea


Bu soru tekrar sordum, ve benzeri tartışılan metada, mevcut en iyi uygulamalar, bu istendiğinde 2009 yılında mevcut olandan daha iyi yaklaşımlar sağlar. Bu cevap bazı güncel çözümler sunmaya çalışıyor. işbirlikçi web geliştirme ortamlarını güvenli bir şekilde ele alma.


Güvenli bir web sunucusu ve ortak geliştirme için yalnızca dosya izinlerinden daha fazlası vardır:

  • Her site için ayrı kullanıcı var yani, tüm siteleri kullanmayın www-data. Bu, bugünlerde Apache'nin nadiren hizmet ettiği için önemlidir. statik içerik dosyaları, ancak çalışıyor dinamik web siteleri Bu cevap PHP’de olduğu gibi en yaygın sunucu site dili, ama aynı prensipler diğerleri için de geçerlidir.

    Tek bir sitede güvenlik sorununuz varsa, aynı kullanıcı olarak çalışan her siteye yayılabilir. Saldırgan, kullanıcının veritabanı giriş bilgileri de dahil olmak üzere gördüğü her şeyi görebilir ve kullanıcının yazma izni olan her siteyi değiştirebilir.

  • kullanım SSH Dosya Aktarım Protokolü (SFTP). FTP'yi kullanırken güvenlik için terk edilmelidir (hem parolaları hem de içeriği düz metinde gönderdiği için), güvenli yerine geçen SFTP'nin de ortak web geliştirme için mükemmel bir çözüm özelliği vardır.

    Siteleri ve site başına bir kullanıcıyı ayırdıktan sonra, web geliştiricilerine, bu sorunun ne hakkında olduğu hakkında erişim vermeniz gerekir. Bu site kullanıcıları için parolaları vermek yerine - veya başlangıçta önerildiği gibi kişisel kullanıcı hesaplarını kullanarak site dosyalarına erişmekten daha fazlasını kullanabilirsiniz. SSH anahtarları giriş için.

    Her geliştirici keypair oluşturabilir ve gizli anahtarı gizli tutabilir. Daha sonra, ortak anahtar eklenir. ~/.ssh/authorized_keys geliştirici üzerinde çalışıyor her web sitesi kullanıcı hesabı için dosya. Bu şifreleri ve girişleri yönetmek için birçok avantajı vardır:

    • Her geliştirici, site başına kullanıcı düzenlemesiyle ilgili tüm parolaları hatırlama veya saklama yükümlülüğü olmadan herhangi bir sayıda web sitesine erişebilir.

    • Şirketten her ayrılışında parolaları değiştirmeye ve paylaşmaya gerek yok.

    • Çok güçlü parolalar kullanabilir veya parola tabanlı oturum açmayı tamamen devre dışı bırakabilirsiniz.

  • PHP-FPM kullan. PHP'yi kullanıcı olarak çalıştırmak için güncel bir yaklaşım. Yeni bir tane oluştur havuz Her kullanıcı için, yani her site için bir havuz. Tek bir sitenin ne kadar kaynak tüketebileceğini de belirleyebileceğiniz için, hem güvenlik hem de performans açısından en iyisi budur.

    Bakınız örn. NeverEndingSecurity en Php-fpm'yi ayrı kullanıcı / kullanıcı kimliği ile çalıştırın ve linux'da gruplayın. HowtoForge gibi öğreticiler var Ubuntu'da Apache ile PHP-FPM Kullanımı 16.04 Bu, kullanıcı ayırma yoluyla güvenliği artırmak için PHP-FPM kullanmaz ve sunucu genelinde tek bir FPM soketini kullanmayı yönlendirir.


7
2018-05-10 10:03