โซลูชันที่โพสต์โดย bgles เป็นจุดเริ่มต้นสำหรับฉันในแง่ของการตั้งค่าสิทธิ์อย่างถูกต้องในตอนแรก (ฉันใช้วิธีที่สอง) แต่ก็ยังมีปัญหาที่อาจเกิดขึ้นสำหรับ Laravel
โดยค่าเริ่มต้น Apache จะสร้างไฟล์ที่มีสิทธิ์ 644 นั่นคือทุกอย่างในการจัดเก็บ / ดังนั้นหากคุณลบเนื้อหาของการจัดเก็บ / กรอบ / มุมมองจากนั้นเข้าถึงหน้าผ่าน Apache คุณจะพบว่ามุมมองแคชถูกสร้างขึ้นเช่น:
-rw-r--r-- 1 www-data www-data 1005 Dec 6 09:40 969370d7664df9c5206b90cd7c2c79c2
หากคุณเรียกใช้ "artisan เสิร์ฟ" และเข้าถึงหน้าอื่นคุณจะได้รับสิทธิ์ที่แตกต่างกันเนื่องจาก CLI PHP ทำงานแตกต่างจาก Apache:
-rw-rw-r-- 1 user www-data 16191 Dec 6 09:48 2a1683fac0674d6f8b0b54cbc8579f8e
ในตัวเองนี่ไม่ใช่เรื่องใหญ่เพราะคุณจะไม่ทำสิ่งนี้ในการผลิต แต่ถ้า Apache สร้างไฟล์ที่ผู้ใช้ต้องเขียนในเวลาต่อมามันจะล้มเหลว และสิ่งนี้สามารถนำไปใช้กับไฟล์แคชมุมมองแคชและบันทึกเมื่อปรับใช้โดยใช้ผู้ใช้และช่างฝีมือเข้าสู่ระบบ ตัวอย่างแบบง่าย ๆ คือ "artisan cache: clear" ซึ่งจะไม่สามารถลบไฟล์แคชใด ๆ ที่เป็นข้อมูล www: ข้อมูล www 644
สิ่งนี้สามารถลดลงได้บางส่วนโดยการใช้คำสั่งช่างเป็น www-data ดังนั้นคุณจะทำ / สคริปต์ทุกอย่างเช่น:
sudo -u www-data php artisan cache:clear
หรือคุณจะหลีกเลี่ยงความน่าเบื่อของสิ่งนี้และเพิ่มลงใน. bash_aliases ของคุณ:
alias art='sudo -u www-data php artisan'
สิ่งนี้ดีพอและไม่มีผลต่อความปลอดภัย แต่อย่างใด แต่สำหรับเครื่องที่พัฒนาแล้วการรันสคริปต์ทดสอบและการสุขาภิบาลทำให้สิ่งนี้ไม่น่าเชื่อถ้าคุณต้องการตั้งชื่อแทนให้ใช้ 'sudo -u www-data' เพื่อเรียกใช้ phpunit และทุกอย่างที่คุณตรวจสอบบิลด์ของคุณอาจทำให้ไฟล์ถูกสร้างขึ้น
วิธีแก้ไขคือทำตามส่วนที่สองของคำแนะนำ bgles และเพิ่มต่อไปนี้ใน / etc / apache2 / envvars และรีสตาร์ท (ไม่รีโหลด) Apache:
umask 002
สิ่งนี้จะบังคับให้ Apache สร้างไฟล์เป็น 664 โดยค่าเริ่มต้น ในตัวเองนี้สามารถนำเสนอความเสี่ยงด้านความปลอดภัย อย่างไรก็ตามในสภาพแวดล้อม Laravel ส่วนใหญ่ถูกกล่าวถึงที่นี่ (Homestead, Vagrant, Ubuntu) เว็บเซิร์ฟเวอร์ทำงานเป็นผู้ใช้ www-data ภายใต้กลุ่ม www-data ดังนั้นหากคุณไม่อนุญาตให้ผู้ใช้เข้าร่วมกลุ่ม www-data โดยพลการไม่ควรมีความเสี่ยงเพิ่มเติม หากมีคนจัดการทำลายเว็บเซิร์ฟเวอร์พวกเขามีระดับการเข้าถึงข้อมูลดาต้าดาต้าอยู่แล้วดังนั้นจึงไม่มีอะไรสูญหาย ดังนั้นในการผลิตมันค่อนข้างปลอดภัยและบนเครื่องที่พัฒนาโดยผู้ใช้คนเดียวมันก็ไม่เป็นปัญหา
ท้ายที่สุดเมื่อผู้ใช้ของคุณอยู่ในกลุ่ม www-data และไดเรกทอรีทั้งหมดที่มีไฟล์เหล่านี้คือ g + s (ไฟล์จะถูกสร้างขึ้นภายใต้กลุ่มของไดเรกทอรีหลัก) ทุกสิ่งที่สร้างโดยผู้ใช้หรือโดย www-data จะเป็น r / w สำหรับคนอื่น ๆ
และนั่นคือจุดมุ่งหมายที่นี่
แก้ไข
ในการตรวจสอบวิธีการข้างต้นเพื่อตั้งค่าการอนุญาตเพิ่มเติมมันยังดูดีพอ แต่การปรับแต่งเล็กน้อยสามารถช่วยได้:
ตามค่าดีฟอลต์แล้วไดเร็กทอรีคือ 775 และไฟล์คือ 664 และไฟล์ทั้งหมดมีเจ้าของและกลุ่มของผู้ใช้ที่เพิ่งติดตั้งเฟรมเวิร์ก สมมติว่าเราเริ่มจากจุดนั้น
cd /var/www/projectroot
sudo chmod 750 ./
sudo chgrp www-data ./
สิ่งแรกที่เราทำคือบล็อกการเข้าถึงทุกคนและทำให้กลุ่มเป็นข้อมูล www มีเพียงเจ้าของและสมาชิกของ www-data เท่านั้นที่สามารถเข้าถึงไดเรกทอรี
sudo chmod 2775 bootstrap/cache
sudo chgrp -R www-data bootstrap/cache
เพื่ออนุญาตให้เว็บเซิร์ฟเวอร์สร้าง services.json และ compiled.php ตามที่แนะนำโดยคู่มือการติดตั้ง Laravel อย่างเป็นทางการ การตั้งค่ากลุ่มจุดยึดหมายความว่าผู้สร้างเหล่านี้เป็นเจ้าของด้วยกลุ่มข้อมูล www
find storage -type d -exec sudo chmod 2775 {} \;
find storage -type f -exec sudo chmod 664 {} \;
sudo chgrp -R www-data storage
เราทำสิ่งเดียวกันกับโฟลเดอร์หน่วยเก็บข้อมูลเพื่ออนุญาตให้สร้างแคชบันทึกเซสชันและดูไฟล์ เราใช้ find เพื่อตั้งค่าการอนุญาตไดเรกทอรีอย่างชัดเจนสำหรับไดเรกทอรีและไฟล์ เราไม่จำเป็นต้องทำเช่นนี้ใน bootstrap / cache เนื่องจากไม่มีไดเรกทอรีย่อยอยู่ในนั้น
คุณอาจจำเป็นต้องใช้แฟล็กที่สามารถเรียกใช้งานได้อีกครั้งและลบผู้ขาย / * และติดตั้งการอ้างอิงผู้แต่งเพื่อติดตั้งลิงก์ใหม่สำหรับ phpunit และ al เช่น:
chmod +x .git/hooks/*
rm vendor/*
composer install -o
แค่นั้นแหละ. ยกเว้น umask สำหรับ Apache ที่อธิบายไว้ข้างต้นนี่คือทั้งหมดที่จำเป็นโดยไม่ต้องทำให้ projectroot ทั้งหมดสามารถเขียนได้โดยข้อมูล www ซึ่งเป็นสิ่งที่เกิดขึ้นกับโซลูชันอื่น ๆ ดังนั้นจึงปลอดภัยกว่าด้วยวิธีนี้เมื่อผู้บุกรุกที่ทำงานในรูปแบบข้อมูล www มีการเข้าถึงการเขียนที่ จำกัด มากขึ้น
สิ้นสุดการแก้ไข
การเปลี่ยนแปลงสำหรับ Systemd
สิ่งนี้ใช้กับการใช้ php-fpm แต่อาจใช้กับคนอื่นด้วย
เซอร์วิส systemd มาตรฐานจำเป็นต้องถูกเขียนทับการตั้ง umask ในไฟล์ override.conf และเซอร์วิสรีสตาร์ท:
sudo systemctl edit php7.0-fpm.service
Use:
[Service]
UMask=0002
Then:
sudo systemctl daemon-reload
sudo systemctl restart php7.0-fpm.service
777เป็นอิสระมากเกินไปเพราะมันรวมสิทธิ์ทั้งหมดสำหรับทุกคน