Solusi yang diposting oleh bgles tepat bagi saya dalam hal mengatur izin dengan benar pada awalnya (saya menggunakan metode kedua), tetapi masih memiliki potensi masalah untuk Laravel.
Secara default, Apache akan membuat file dengan 644 izin. Jadi itu cukup banyak dalam penyimpanan /. Jadi, jika Anda menghapus konten storage / framework / views, maka akses halaman melalui Apache Anda akan menemukan tampilan cache telah dibuat seperti:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
Jika Anda menjalankan "artisan serve" dan mengakses halaman yang berbeda, Anda akan mendapatkan izin yang berbeda karena CLI PHP berperilaku berbeda dari Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
Dalam dirinya sendiri ini bukan masalah besar karena Anda tidak akan melakukan semua ini dalam produksi. Tetapi jika Apache membuat file yang selanjutnya harus ditulis oleh pengguna, itu akan gagal. Dan ini dapat berlaku untuk file cache, tampilan cache dan log saat menggunakan menggunakan pengguna dan artisan login. Contoh yang mudah adalah "artisan cache: clear" yang akan gagal menghapus file cache apa pun yang merupakan www-data: www-data 644.
Ini dapat dikurangi sebagian dengan menjalankan perintah artisan sebagai www-data, jadi Anda akan melakukan / scripting semuanya seperti:
sudo -u www-data php artisan cache:clear
Atau Anda akan menghindari kebosanan ini dan menambahkan ini ke .bash_aliases Anda:
alias art='sudo -u www-data php artisan'
Ini cukup bagus dan tidak mempengaruhi keamanan dengan cara apa pun. Tetapi pada mesin pengembangan, menjalankan skrip pengujian dan sanitasi membuat ini sulit, kecuali jika Anda ingin membuat alias untuk menggunakan 'sudo -u www-data' untuk menjalankan phpunit dan segala sesuatu yang Anda periksa build Anda dengan yang dapat menyebabkan file dibuat.
Solusinya adalah dengan mengikuti saran bgles bagian kedua, dan tambahkan yang berikut ke / etc / apache2 / envvars, dan mulai ulang (tidak muat ulang) Apache:
umask 002
Ini akan memaksa Apache untuk membuat file sebagai 664 secara default. Dalam dirinya sendiri, ini dapat menghadirkan risiko keamanan. Namun, pada lingkungan Laravel sebagian besar sedang dibahas di sini (Homestead, Vagrant, Ubuntu) server web berjalan sebagai data-pengguna www di bawah grup data-www. Jadi jika Anda tidak secara sewenang-wenang mengizinkan pengguna untuk bergabung dengan grup data-www, seharusnya tidak ada risiko tambahan. Jika seseorang berhasil keluar dari server web, mereka memiliki tingkat akses www-data sehingga tidak ada yang hilang (meskipun itu bukan sikap terbaik untuk berhubungan dengan keamanan diakui). Jadi pada produksi relatif aman, dan pada mesin pengembangan pengguna tunggal, itu tidak masalah.
Pada akhirnya ketika pengguna Anda berada di grup data-www, dan semua direktori yang berisi file-file ini adalah g + s (file selalu dibuat di bawah grup direktori induk), apa pun yang dibuat oleh pengguna atau oleh data-www akan menjadi r / untuk yang lain.
Dan itulah tujuannya di sini.
sunting
Saat menyelidiki pendekatan di atas untuk menetapkan izin lebih lanjut, masih terlihat cukup baik, tetapi beberapa penyesuaian dapat membantu:
Secara default, direktori adalah 775 dan file 664 dan semua file memiliki pemilik dan grup pengguna yang baru saja menginstal framework. Jadi asumsikan kita mulai dari titik itu.
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
Hal pertama yang kami lakukan adalah memblokir akses ke orang lain, dan menjadikan grup sebagai data-www. Hanya pemilik dan anggota www-data yang dapat mengakses direktori.
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
Untuk memungkinkan server web membuat services.json dan compiled.php, seperti yang disarankan oleh panduan instalasi Laravel resmi. Mengatur bit sticky grup berarti ini akan dimiliki oleh pembuatnya dengan grup data-www.
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
Kami melakukan hal yang sama dengan folder penyimpanan untuk memungkinkan pembuatan cache, log, sesi dan melihat file. Kami menggunakan find untuk secara eksplisit mengatur izin direktori secara berbeda untuk direktori dan file. Kami tidak perlu melakukan ini di bootstrap / cache karena tidak ada (biasanya) sub-direktori di sana.
Anda mungkin perlu menerapkan kembali flag yang dapat dieksekusi, dan menghapus vendor / * dan menginstal ulang dependensi komposer untuk membuat ulang tautan untuk phpunit et al, mis .:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
Itu dia. Kecuali umask untuk Apache yang dijelaskan di atas, ini semua yang diperlukan tanpa membuat seluruh projectroot dapat ditulis oleh www-data, yang merupakan apa yang terjadi dengan solusi lain. Jadi sedikit lebih aman dengan cara ini karena penyusup berjalan karena www-data memiliki akses tulis yang lebih terbatas.
akhiri edit
Perubahan untuk Systemd
Ini berlaku untuk penggunaan php-fpm, tapi mungkin juga orang lain.
Layanan systemd standar perlu diganti, umask diatur dalam file override.conf, dan layanan restart:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777terlalu banyak kebebasan, karena itu mencakup semua izin untuk semua orang.