Bgles tarafından gönderilen çözüm, başlangıçta izinlerin doğru ayarlanması açısından bana göre (ikinci yöntemi kullanıyorum), ancak yine de Laravel için potansiyel sorunları var.
Apache varsayılan olarak 644 izinli dosyalar oluşturur. Bu depolamada hemen hemen her şey. Bu nedenle, depolama / çerçeve / görünümlerin içeriğini silerseniz, bir sayfaya Apache üzerinden erişirseniz, önbelleğe alınmış görünümün aşağıdaki gibi oluşturulduğunu göreceksiniz:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
"Esnaf hizmetini" çalıştırır ve farklı bir sayfaya erişirseniz CLI PHP'nin Apache'den farklı davrandığı için farklı izinler alırsınız:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
Kendi başına bu hiç önemli değil çünkü üretimde bunların hiçbirini yapmayacaksınız. Ancak Apache daha sonra kullanıcı tarafından yazılması gereken bir dosya oluşturursa başarısız olur. Bu , oturum açmış bir kullanıcı ve esnaf kullanarak dağıtırken önbellek dosyaları, önbelleğe alınmış görünümler ve günlükler için de geçerlidir. Www-data: www-data 644 önbellek dosyalarını silmeyecek olan "zanaatkar önbellek: temizle" gibi kolay bir örnek.
Bu, esnaf komutlarını www-data olarak çalıştırarak kısmen azaltılabilir, bu nedenle aşağıdaki gibi her şeyi yaparsınız / komut dosyası yazarsınız:
sudo -u www-data php artisan cache:clear
Ya da bunun sıkıcılığından kaçınacak ve bunu .bash_aliases'ınıza ekleyeceksiniz:
alias art='sudo -u www-data php artisan'
Bu yeterince iyidir ve güvenliği hiçbir şekilde etkilemez. Ancak, phpunit'i çalıştırmak için 'sudo -u www-data' kullanmak için takma adlar ayarlamak istemediğiniz sürece geliştirme makinelerinde, test ve sanitasyon komut dosyalarını çalıştırmak bu hantal değildir.
Çözüm, bgles tavsiyesinin ikinci bölümünü takip etmek ve / etc / apache2 / envvars'a aşağıdakileri eklemek ve Apache'yi yeniden başlatmak (yeniden yüklememek):
umask 002
Bu, Apache'yi varsayılan olarak 664 olarak dosya oluşturmaya zorlar. Kendi başına, bu bir güvenlik riski oluşturabilir. Ancak, çoğunlukla burada tartışılan Laravel ortamlarında (Homestead, Vagrant, Ubuntu) web sunucusu, www-data grubu altında kullanıcı www-data olarak çalışır. Dolayısıyla, kullanıcıların keyfi olarak www-data grubuna katılmasına izin vermezseniz, ek bir risk olmamalıdır. Birisi web sunucusundan çıkmayı başarırsa, yine de www-veri erişim seviyesine sahiptir, bu yüzden hiçbir şey kaybolmaz (ancak bu, güvenlikle ilgili olarak en iyi tutum değildir). Bu nedenle üretimde nispeten güvenlidir ve tek kullanıcılı bir geliştirme makinesinde bu bir sorun değildir.
Nihayetinde kullanıcınız www-veri grubunda olduğundan ve bu dosyaları içeren tüm dizinler g + s'dir (dosya her zaman üst dizin grubu altında oluşturulur), kullanıcı veya www-data tarafından oluşturulan her şey r / w diğeri için.
Ve buradaki amaç bu.
Düzenle
İzinleri daha da ayarlamak için yukarıdaki yaklaşımı araştırırken, yine de yeterince iyi görünüyor, ancak birkaç ayar yardımcı olabilir:
Varsayılan olarak, dizinler 775 ve dosyalar 664'tür ve tüm dosyalar, çerçeveyi yeni yükleyen kullanıcının sahibi ve grubuna sahiptir. Diyelim ki o noktadan başlıyoruz.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
Yaptığımız ilk şey, herkese erişimi engellemek ve grubun www-veri olmasını sağlamaktır. Dizine yalnızca www verilerinin sahibi ve üyeleri erişebilir.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Web sunucusunun resmi Laravel kurulum kılavuzu tarafından önerildiği gibi services.json ve compiled.php oluşturmasına izin vermek için. Grup yapışkan bitinin ayarlanması, bunların bir grup www verisine sahip içerik oluşturucuya ait olacağı anlamına gelir.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Önbellek, günlük, oturum ve görüntüleme dosyalarının oluşturulmasına izin vermek için depolama klasöründe de aynı şeyi yaparız. Find dizinini, dizinler ve dosyalar için dizin izinlerini açıkça farklı bir şekilde ayarlamak için kullanırız. Bunu (normalde) herhangi bir alt dizin olmadığı için bootstrap / cache'de yapmamız gerekmiyordu.
Phpunit ve diğerlerinin bağlantılarını yeniden oluşturmak için yürütülebilir bayrakları yeniden uygulamanız ve satıcı / * silmeniz ve besteci bağımlılıklarını yeniden yüklemeniz gerekebilir;
chmod +x .git/hooks/*
rm vendor/*
composer install -o
Bu kadar. Yukarıda açıklanan Apache için umask dışında, tüm proje kökünü www-data ile yazılabilir hale getirmeden gereken tek şey budur, diğer çözümlerle olan şey budur. Bu nedenle, www-data olarak çalışan bir davetsiz misafirin daha sınırlı yazma erişimine sahip olması marjinal olarak daha güvenlidir.
düzenlemeyi bitir
Systemd'deki değişiklikler
Bu php-fpm, ama belki diğerleri için de geçerlidir.
Standart systemd hizmetinin geçersiz kılınması, override.conf dosyasında umask ayarlanması ve hizmetin yeniden başlatılması gerekir:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777çok fazla özgürlük var, çünkü herkes için tüm izinleri içeriyor.