วิธีการตั้งค่าการอนุญาต linux สำหรับโฟลเดอร์ WWW?


69

อัปเดตข้อมูลสรุป

ไดเรกทอรี / var / www เป็นเจ้าของroot:rootซึ่งหมายความว่าไม่มีใครสามารถใช้งานได้และไม่มีประโยชน์อย่างสิ้นเชิง เนื่องจากเราทุกคนต้องการเว็บเซิร์ฟเวอร์ที่ใช้งานได้จริง (และไม่มีใครควรเข้าสู่ระบบในฐานะ "รูท") ดังนั้นเราจึงต้องแก้ไขปัญหานี้

มีเพียงสองหน่วยงานเท่านั้นที่ต้องมีการเข้าถึง

  1. PHP / Perl / Ruby / Pythonทุกคนต้องการการเข้าถึงโฟลเดอร์และไฟล์เนื่องจากมันสร้างขึ้นมาจำนวนมาก (เช่น/uploads/) ภาษาสคริปต์เหล่านี้ควรทำงานภายใต้ nginx หรือ apache (หรือแม้แต่สิ่งอื่น ๆ เช่น FastCGI สำหรับ PHP)

  2. นักพัฒนา

พวกเขาเข้าถึงได้อย่างไร ฉันรู้ว่ามีบางคนเคยทำสิ่งนี้มาก่อน ด้วยเว็บไซต์ที่มีอยู่หลายพันล้านแห่งคุณคิดว่าจะมีข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้


ฉันรู้ว่า 777 เต็มสิทธิ์อ่าน / เขียน / ดำเนินการสำหรับเจ้าของ / กลุ่ม / อื่น ๆ ดังนั้นจึงไม่จำเป็นต้องแก้ไขให้ถูกต้องเนื่องจากจะให้สิทธิ์แบบเต็มแก่ผู้ใช้

ต้องใช้การอนุญาตอะไรบ้าง/var/wwwเพื่อให้:

  1. การควบคุมแหล่งที่มาเช่น git หรือ svn
  2. ผู้ใช้ในกลุ่มเช่น "เว็บไซต์" ( หรือเพิ่มลงใน "www-data" )
  3. เซิร์ฟเวอร์เช่น apache หรือ lighthttpd
  4. และ PHP / Perl / Ruby

ทุกคนสามารถอ่านสร้างและเรียกใช้ไฟล์ (และไดเรกทอรี) ได้ไหม

หากฉันถูกต้องสคริปต์ Ruby และ PHP จะไม่ "ดำเนินการ" โดยตรง - แต่ส่งต่อไปยังล่าม ดังนั้นไม่จำเป็นต้องขออนุญาตดำเนินการกับไฟล์ใน/var/www... ดังนั้นดูเหมือนว่าสิทธิ์ที่ถูกต้องจะเป็นchmod -R 1660สิ่งที่จะทำให้

  1. ไฟล์ทั้งหมดใช้ร่วมกันโดยสี่หน่วยงานเหล่านี้
  2. ไฟล์ทั้งหมดไม่สามารถเรียกใช้งานได้โดยไม่ได้ตั้งใจ
  3. บล็อกคนอื่นจากไดเรกทอรีทั้งหมด
  4. ตั้งค่าโหมดการอนุญาตเป็น "เหนียว" สำหรับไฟล์ในอนาคตทั้งหมด

ถูกต้องหรือไม่

อัปเดต 1:ฉันเพิ่งรู้ว่าไฟล์และไดเรกทอรีอาจต้องมีการอนุญาตที่แตกต่างกัน - ฉันกำลังพูดถึงไฟล์ด้านบนดังนั้นฉันไม่แน่ใจว่าต้องใช้สิทธิ์ไดเรกทอรีใด

อัปเดต 2:โครงสร้างโฟลเดอร์ของ/var/wwwการเปลี่ยนแปลงอย่างมากเนื่องจากหนึ่งในสี่เอนทิตีข้างต้นมักจะเพิ่ม (และบางครั้งลบ) โฟลเดอร์และโฟลเดอร์ย่อยหลายระดับ พวกเขายังสร้างและลบไฟล์ที่เอนทิตี 3 อื่น ๆ อาจต้องมีการเข้าถึงแบบอ่าน / เขียน ดังนั้นการอนุญาตต้องทำทั้งสี่อย่างข้างต้นสำหรับทั้งไฟล์และไดเรกทอรี เนื่องจากไม่มีสิ่งใดที่ควรได้รับอนุญาตให้ดำเนินการ (ดูคำถามเกี่ยวกับ ruby ​​/ php ด้านบน) ฉันคิดว่าการrw-rw-r--อนุญาตจะเป็นสิ่งที่จำเป็นและปลอดภัยอย่างสมบูรณ์เนื่องจากองค์กรทั้งสี่นี้ดำเนินการโดยบุคลากรที่เชื่อถือได้ (ดู # 2) และผู้ใช้อื่น ๆ ระบบมีการเข้าถึงเพื่ออ่านเท่านั้น

อัปเดต 3: ใช้สำหรับเครื่องพัฒนาส่วนบุคคลและเซิร์ฟเวอร์ บริษัท ส่วนตัว ไม่มี "ลูกค้าเว็บ" แบบสุ่มเหมือนโฮสต์ที่ใช้ร่วมกัน

อัปเดต 4: บทความนี้โดย slicehost ดูเหมือนจะดีที่สุดในการอธิบายสิ่งที่จำเป็นในการตั้งค่าการอนุญาตสำหรับโฟลเดอร์ www ของคุณ อย่างไรก็ตามฉันไม่แน่ใจว่าผู้ใช้หรือกลุ่ม apache / nginx ที่มี PHP หรือ svn / git ทำงานเป็นและวิธีการเปลี่ยนพวกเขา

อัปเดต 5:ฉันมี (ฉันคิดว่า) ในที่สุดก็พบวิธีที่จะทำให้ทุกอย่างทำงานได้ (คำตอบด้านล่าง) อย่างไรก็ตามฉันไม่รู้ว่านี่เป็นวิธีที่ถูกต้องและปลอดภัยหรือไม่ ดังนั้นฉันได้เริ่มต้นเงินรางวัล บุคคลที่มีวิธีที่ดีที่สุดในการรักษาความปลอดภัยและจัดการไดเรกทอรี www ชนะ

คำตอบ:


47

หลังจากการวิจัยเพิ่มเติมดูเหมือนว่าอีกวิธีหนึ่ง (อาจเป็นวิธีที่ดีกว่า) ในการตอบคำถามนี้คือการตั้งค่าโฟลเดอร์ www อย่างนั้น

  1. sudo usermod -a -G developer user1 (เพิ่มผู้ใช้แต่ละรายในกลุ่มนักพัฒนา)
  2. sudo chgrp -R developer /var/www/site.com/ เพื่อให้นักพัฒนาสามารถทำงานได้ที่นั่น
  3. sudo chmod -R 2774 /var/www/site.com/ เพื่อให้ผู้พัฒนาเท่านั้นที่สามารถสร้าง / แก้ไขไฟล์ (อื่น ๆ / โลกสามารถอ่านได้)
  4. sudo chgrp -R www-data /var/www/site.com/uploads เพื่อให้ www-data (apache / nginx) สามารถสร้างการอัปโหลด

ตั้งแต่gitวิ่งเป็นสิ่งที่ผู้ใช้จะเรียกมันว่าแล้วตราบใดที่ผู้ใช้อยู่ใน "นักพัฒนา" กลุ่มพวกเขาควรจะสามารถที่จะสร้างโฟลเดอร์แก้ไขไฟล์ PHP และจัดการพื้นที่เก็บข้อมูลคอมไพล์

หมายเหตุ: ในขั้นตอน (3): '2' ใน 2774 หมายถึง 'ตั้งค่า Group ID' สำหรับไดเรกทอรี สิ่งนี้ทำให้ไฟล์ใหม่และไดเร็กทอรีย่อยที่สร้างขึ้นภายในสืบทอด ID กลุ่มของไดเร็กทอรีพาเรนต์ (แทนกลุ่มหลักของผู้ใช้) การอ้างอิง: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories


ดูสมเหตุสมผลสำหรับฉัน
wazoox

ดี. บางทีถ้าฉันสามารถยืนยันกับคนอื่นอีกสองสามคนฉันจะใช้วิธีนี้ ดูเหมือนว่าจะเป็นคำตอบที่ดีที่สุดที่ฉันสามารถบีบคนออกได้
Xeoncross

คุณไม่ได้ระบุว่าใครจะเป็นเจ้าของไฟล์ คุณจะปล่อยให้มันเป็นราก? จากนั้น sudoers เท่านั้นที่สามารถแก้ไขโฟลเดอร์ที่อัปโหลดของคุณ (อาจไม่ใช่สิ่งที่คุณตั้งใจ)
Nic

ใช่รากจะยังคงเป็นเจ้าของ อย่างไรก็ตามเนื่องจากเจ้าของกลุ่มเป็น "ผู้พัฒนา" (และมีสิทธิ์ wrx) ดังนั้น devs ทั้งหมด (และ apache / nginx) จึงสามารถอ่านได้ ไม่จำเป็นต้องใช้ sudo
Xeoncross

7
อีกอย่างที่ต้องระวังคือ umask หลายระบบมีค่าเริ่มต้น umask เป็น 022 ซึ่งจะลบสิทธิ์การเขียนสำหรับทั้งกลุ่มและสาธารณะในไฟล์ใหม่ ฉันสงสัยว่าคุณต้องการ 002 (ไม่เขียนสู่สาธารณะ) หรือ 007 (ไม่สามารถเข้าถึงเพื่อสาธารณะ) คุณสามารถตั้งค่า umask ในการกำหนดค่าของ Apache และ / หรือสคริปต์เริ่มต้นสำหรับกระบวนการใด ๆ ที่ต้องการเข้าถึงไดเรกทอรี อย่าลืมที่จะเพิ่มสิ่งนี้ลงใน / etc / profile หรือ / etc / bashrc เพื่อให้มันถูกกำหนดโดยค่าเริ่มต้นสำหรับนักพัฒนาของคุณเช่นกัน
Mark Porter

8

ฉันไม่แน่ใจว่าเป็น "ถูกต้อง" แต่นี่คือสิ่งที่ฉันทำบนเซิร์ฟเวอร์ของฉัน:

  • / var / www มีโฟลเดอร์สำหรับแต่ละเว็บไซต์
  • แต่ละเว็บไซต์มีเจ้าของที่ได้รับมอบหมายซึ่งถูกกำหนดให้เป็นเจ้าของไฟล์และโฟลเดอร์ทั้งหมดในไดเรกทอรีของเว็บไซต์
  • ผู้ใช้ทั้งหมดที่ดูแลเว็บไซต์จะถูกจัดกลุ่มเป็นกลุ่มสำหรับเว็บไซต์
  • กลุ่มนี้ถูกตั้งเป็นเจ้าของกลุ่มของไฟล์และโฟลเดอร์ทั้งหมดในไดเรกทอรี
  • ไฟล์หรือโฟลเดอร์ใด ๆ ที่จำเป็นต้องเขียนโดยเว็บเซิร์ฟเวอร์ (เช่น. PHP) ได้เปลี่ยนเจ้าของเป็น www-data ผู้ใช้ที่ apache ทำงานภายใต้

โปรดทราบว่าคุณควรเปิดใช้งานบิตรันบนไดเร็กทอรีเพื่อให้คุณสามารถแสดงรายการเนื้อหา


git / svn หรือ PHP สร้างโฟลเดอร์ใหม่ได้อย่างไร
Xeoncross

2
PHP ทำงานในบริบทของผู้ใช้เดียวกับเว็บเซิร์ฟเวอร์ดังนั้นจึงสามารถสร้างไฟล์และโฟลเดอร์ในไดเรกทอรีใด ๆ ที่เป็นของเว็บเซิร์ฟเวอร์ โดยทั่วไปจะมีเพียงไม่กี่โฟลเดอร์เช่นนี้ (/ uploads / เป็นต้น) ฉันไม่แน่ใจเกี่ยวกับ git / svn - คุณสามารถเพิ่มพวกเขาไปยังบัญชีกลุ่มที่ควบคุมเว็บไซต์ได้หรือไม่
Nic

เห็นได้ชัดว่าคอมไพล์รันในขณะที่ผู้ใช้เรียกใช้ - เช่นเดียวกับเครื่องมืออื่น ๆ
Xeoncross

จากนั้นเพิ่มผู้ใช้ git ในกลุ่ม apache และให้สิทธิ์การเขียนกลุ่มโฟลเดอร์
David Rickman

ฉันเพิ่งพูดว่าคอมไพล์ไม่มีผู้ใช้ - มันทำงานเป็นผู้ใช้ปัจจุบันใช้
Xeoncross

7

หลังจากทำการวิจัยเพิ่มเติมดูเหมือนว่า git / svn TOOLSจะไม่เกิดปัญหาเนื่องจากทำงานเป็นสิ่งที่ผู้ใช้ใช้ (อย่างไรก็ตาม git / svn daemons เป็นเรื่องที่แตกต่างกัน!) ทุกอย่างที่ฉันสร้าง / โคลนด้วย git มีสิทธิ์ของฉันและเครื่องมือ git ได้รับการจดทะเบียนใน/usr/binที่เหมาะกับวิทยานิพนธ์นี้

แก้ไขสิทธิ์ Git แล้ว

ดูเหมือนว่าสิทธิ์ของผู้ใช้จะสามารถแก้ไขได้โดยการเพิ่มผู้ใช้ทั้งหมดที่ต้องการเข้าถึงไดเรกทอรี www ไปยังwww-dataกลุ่มที่ apache (และ nginx) ทำงานเป็น

ดังนั้นดูเหมือนว่าคำตอบเดียวสำหรับคำถามนี้จะเป็นเช่นนี้:

โดยค่าเริ่มต้น/var/wwwจะเป็นเจ้าของroot:rootและไม่มีใครสามารถเพิ่มหรือเปลี่ยนแปลงไฟล์ได้

1) เปลี่ยนเจ้าของกลุ่ม

ก่อนอื่นเราต้องเปลี่ยนกลุ่มไดเรกทอรี www ให้เป็นของ "www-data" แทนกลุ่ม "root"

sudo chgrp -R www-data /var/www

2) เพิ่มผู้ใช้ไปยัง www-data

จากนั้นเราจำเป็นต้องเพิ่มผู้ใช้ปัจจุบัน (และคนอื่น ๆ ) ไปยังกลุ่ม www-data

sudo usermod -a -G www-data demousername

3) ไดเรกทอรี CHMOD www

เปลี่ยนการอนุญาตเพื่อให้เฉพาะเจ้าของ (root) และผู้ใช้ทั้งหมดในกลุ่ม "www-data" สามารถ rwx (อ่าน / เขียน / ดำเนินการ) ไฟล์และไดเรกทอรี ( ไม่มีใครสามารถเข้าถึงได้เลย )

sudo chmod -R 2770 /var/www

ตอนนี้ไฟล์และไดเรกทอรีทั้งหมดที่สร้างโดยผู้ใช้ที่มีการเข้าถึง (เช่นในกลุ่ม "www-data") จะสามารถอ่าน / เขียนได้โดย apache และ php

ถูกต้องหรือไม่ ไฟล์ที่ PHP / Ruby สร้างขึ้น - ผู้ใช้ www-data สามารถเข้าถึงไฟล์เหล่านั้นได้หรือไม่?


6
ฉันไม่ชอบความคิดที่มีไฟล์เว็บทั้งหมดที่เขียนได้ด้วย PHP มันจะเพิ่มโอกาสที่คุณจะได้รับหากมีช่องโหว่ของสคริปต์
Nic

ตกลงฉันรู้ว่าฉันใช้ PHP เพื่อสร้างข้อความ, tar, log และไฟล์รูปภาพ (รวมถึงโฟลเดอร์) จำนวนมากดังนั้นฉันแค่คิดว่าทุกอย่างควรจะเขียนได้ อย่างไรก็ตามบางทีสิทธิของคุณและ PHP ควรจะสามารถเปลี่ยนได้เพียงสร้างไฟล์ซึ่งจะไม่เป็นอันตรายเนื่องจาก 99% ของแอพ PHP ทั้งหมดไม่เคยสร้างไฟล์สคริปต์ ตัวเลือกอื่น ๆ ดูเหมือนว่าจะอนุญาตให้เฉพาะบางไดเรกทอรี PHP เข้าถึงการเขียน (/ อัพโหลด /) ซึ่งไม่ได้ทำเพราะเพราะ PHP ยังคงสามารถใช้เพื่อสร้างสิ่งที่ไม่ดีที่นั่น ความคิดใด ๆ
Xeoncross

2
ลองแยกสคริปต์และข้อมูลออก แม้ว่าผู้โจมตีจะปล่อยบางสิ่งบางอย่างใน / uploads / มันก็ไม่ควรที่จะปฏิบัติการได้ ความปลอดภัยในเลเยอร์เป็นกุญแจสำคัญ
Nic

6

Stickiness ไม่ใช่การสืบทอดสิทธิ์ ความหนืดในไดเรกทอรีหมายความว่าเฉพาะเจ้าของไฟล์หรือเจ้าของไดเรกทอรีเท่านั้นที่สามารถเปลี่ยนชื่อหรือลบไฟล์นั้นในไดเรกทอรีได้แม้จะมีการอนุญาตเป็นอย่างอื่น ดังนั้น 1777 บน / tmp /

ใน Unix แบบคลาสสิกไม่มีการสืบทอดสิทธิ์ที่อ้างอิงตามระบบไฟล์เฉพาะใน umask ของกระบวนการปัจจุบันเท่านั้น บน * BSD หรือ Linux ที่มี setgid ในไดเรกทอรีฟิลด์กลุ่มของไฟล์ที่สร้างขึ้นใหม่จะถูกตั้งค่าเช่นเดียวกับของไดเรกทอรีหลัก คุณต้องหา ACLs ด้วย 'default' ACL บนไดเร็กตอรี่ซึ่งอนุญาตให้คุณสืบทอดสิทธิ์

คุณควรเริ่มต้นด้วยการกำหนด: * สิ่งที่ผู้ใช้สามารถเข้าถึงระบบ * รูปแบบการคุกคามของคุณคืออะไร

ตัวอย่างเช่นหากคุณกำลังทำเว็บโฮสติ้งกับลูกค้าหลายรายและคุณไม่ต้องการให้พวกเขาเห็นไฟล์อื่น ๆ คุณอาจใช้ "webcusts" กลุ่มทั่วไปสำหรับผู้ใช้ทั้งหมดและโหมดไดเรกทอรี 0705 จากนั้นให้บริการไฟล์โดย กระบวนการของเว็บเซิร์ฟเวอร์ ( ไม่ใช่ใน "webcusts") จะเห็น perms อื่น ๆ และได้รับอนุญาต ลูกค้าไม่สามารถเห็นไฟล์ของกันและกันและผู้ใช้สามารถยุ่งกับไฟล์ของตัวเอง อย่างไรก็ตามนี่หมายความว่าช่วงเวลาที่คุณอนุญาตให้ CGI หรือ PHP คุณต้องตรวจสอบให้แน่ใจว่ากระบวนการทำงานในฐานะผู้ใช้ที่เฉพาะเจาะจง (แนวปฏิบัติที่ดีสำหรับผู้ใช้หลายคนต่อหนึ่งโฮสต์สำหรับความรับผิดชอบ) มิฉะนั้นลูกค้าอาจยุ่งกับไฟล์ของกันและกันโดยให้ CGI ทำเช่นนั้น

อย่างไรก็ตามหากผู้ใช้ที่ทำการเว็บไซต์เหมือนกันกับเจ้าของเว็บไซต์คุณมีปัญหากับการที่ไม่สามารถปกป้องเนื้อหาจากผู้ใช้ในกรณีที่มีช่องโหว่ในสคริปต์ได้ ซึ่งเป็นที่ที่โฮสต์เฉพาะชนะเพื่อให้คุณสามารถมีผู้ใช้เวลาทำงานแตกต่างจากเจ้าของเนื้อหาคงที่และไม่ต้องกังวลมากเกี่ยวกับการโต้ตอบกับผู้ใช้อื่น ๆ


คำตอบที่ดี. บน MacOS X ระบบจะทำงานเหมือนกับว่าบิต SGID อยู่ในไดเรกทอรีโดยอัตโนมัติ โดยทั่วไปแล้วบิตเหนียวหมายถึงคุณสามารถลบไฟล์ได้เฉพาะเมื่อคุณเขียนได้ นั่นคือทุกคนสามารถลบไฟล์ที่เขียนได้แบบสาธารณะใน / tmp บน MacOS X / tmp เป็น symlink ไปยังไดเรกทอรีส่วนตัวสำหรับผู้ใช้ - ดังนั้นจึงไม่มีการแบ่งปันหลังจากทั้งหมด
Jonathan Leffler

ขอบคุณสำหรับคำตอบฉันได้อัปเดตคำถามด้วยข้อมูลเพิ่มเติม
Xeoncross

Jonathan: บิตเหนียวหมายถึงเฉพาะเจ้าของไดเรกทอรีหรือเจ้าของไฟล์เท่านั้นที่สามารถเปลี่ยนชื่อหรือลบมันได้ (เช่นดำเนินการกับรายการในไดเรกทอรี 'file') สิทธิ์ในแต่ละไฟล์ไม่ได้เข้ามาเล่นสำหรับการดำเนินงานไดเรกทอรีเหล่านี้ ( rename(), unlink()), เฉพาะสำหรับการดำเนินการกับไฟล์เอง ( open()) นี่คือพฤติกรรม "ปกติ"
Phil P

2

ฉันเชื่อว่าวิธีที่ดีที่สุดในการทำเช่นนี้คือการใช้ Posix ACLs พวกเขาสะดวกสบายในการทำงานและนำเสนอฟังก์ชั่นทั้งหมดที่คุณต้องการ

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs


+1 สำหรับข้อมูลที่เป็นประโยชน์เกี่ยวกับของ ACL อย่างไรก็ตามฉันไม่ต้องการให้ขยะเพิ่มลงในระบบเพียงเพื่อจัดการเซิร์ฟเวอร์ที่เรียบง่ายกับนักพัฒนาสองสามคน ฉันไม่สะดวกในการคอมไพล์เคอร์เนลอีกครั้งเพื่อใช้งาน ACL
Xeoncross

@ Xeoncross: ACLs ไม่ชะงักอะไรเลย พวกเขาเป็นเพียงข้อมูลจำลองเช่นการอนุญาตไฟล์ปกติ ไม่ใช่ทั้งหมดที่ "พิเศษ" และซับซ้อนฉันเชื่อว่ามันเป็นวิธีที่ง่ายและดีที่สุดในการจัดการสิทธิ์แทนที่จะสับสนหรือกลุ่ม / วิธีแก้ปัญหาใด ๆ ที่สับสน ไม่ต้องกลัวเพียงแค่ติดตั้ง acl ใหม่และลองดู!
Tie-fighter

1

เจ้าของไฟล์ควรเป็นคนที่สร้างมันขึ้นมาในขณะที่กลุ่มควรเป็น www-data โหมดสำหรับไดเรกทอรี / ไฟล์นั้นโดยทั่วไปคือ 755/644 ในขณะที่สำหรับไดเรกทอรีและไฟล์กลุ่มต้องการเข้าถึงการเขียน mod คือ 775/664 สมมติว่าข้าวเปลือกเป็นผู้พัฒนา ทั้งหมดนี้ทำให้:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;

0

การเพิ่มคำตอบของ @ Xeoncross ฉันคิดว่าเป็นการดีที่จะกำหนดค่าการอนุญาตสำหรับไฟล์และไดเรกทอรีแยกกัน

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

สิ่งนี้จะทำให้นักพัฒนาซอฟต์แวร์สามารถสร้างและปรับเปลี่ยนไดเรกทอรีภายใน / var / www ซึ่งดูเหมือนว่าสำคัญเพราะนักพัฒนาอาจต้องสร้างไดเรกทอรีเพิ่มเติมหรือลบไดเรกทอรีที่ไม่ต้องการอีกต่อไป

นอกจากนี้ยังจะช่วยให้นักพัฒนาสามารถสร้างและแก้ไขไฟล์โค้ด (อ่าน HTML, ไฟล์ PHP และสิ่งที่คล้ายกัน) แต่จะอนุญาตการเข้าถึงแบบอ่านอย่างเดียวสำหรับทุกคนเท่านั้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.