จะปลอดภัยที่จะ chown` / usr / local`?


15

ฉันรู้ว่า/usr/localการติดตั้งซอฟต์แวร์สำหรับเครื่องท้องถิ่นคืออะไร โดยค่าเริ่มต้นrootเป็นเจ้าของไดเรกทอรี sudoซึ่งหมายความว่าการติดตั้งนั้นคุณจำเป็นต้องใช้ สำหรับเครื่องผู้ใช้คนเดียวหรือนักพัฒนาซอฟต์แวร์นี่ดูเหมือนจะเป็นการใช้คำสั่งพิเศษโดยไม่จำเป็น ดังนั้นคำถามของฉัน - มันปลอดภัยสำหรับฉันที่จะเป็นเจ้าของ/usr/local?

ยกตัวอย่างเช่น Homebrew สำหรับ OS X "เพียงธิการ" เพราะพวกเขาเอง/usr/localและปลอดภัยsudoติดตั้งซอฟต์แวร์ของพวกเขาโดยไม่ต้องมีการใช้งานของ

นอกจากนี้หากคุณติดตั้งซอฟต์แวร์ที่คอมไพล์ใน/usr/localเครื่องปัจจุบันซอฟต์แวร์ต้องการรูทเพื่อแก้ไขตนเองหรือติดตั้งปลั๊กอิน นี้ดูเหมือนว่าไม่ปลอดภัย - ฉันต้องการเพียงใช้sudoเมื่อฉันรู้ว่าตรงกับสิ่งที่จะเกิดขึ้น

ความเห็น?

คำตอบ:


5

ฉันไม่สามารถแนะนำให้เป็นเจ้าของ/usr/local; sudoสำหรับสถานการณ์ส่วนใหญ่ก็อาจจะมีความปลอดภัยน้อยกว่าการใช้

chown /usr/localคำถามของคุณแสดงให้เห็นสองเหตุผลที่คุณอาจต้องการ

สิ่งแรกคือหลีกเลี่ยงการใช้sudoเพื่อติดตั้งซอฟต์แวร์ สิ่งนี้อาจอ่านบางส่วน (เช่นผู้เขียนคำตอบนี้ ) ว่าคุณต้องการทำงานอย่างมีประสิทธิภาพหรือบันทึกการกดแป้นที่จำเป็นในการพิมพ์sudoและป้อนรหัสผ่านของคุณ แต่บางทีเมื่อคุณพูดว่า "ไม่จำเป็น" คุณกำลังอ้างถึงหลักการที่มีสิทธิ์น้อยที่สุด :

โดยค่าเริ่มต้นrootเป็นเจ้าของไดเรกทอรี sudoซึ่งหมายความว่าการติดตั้งนั้นคุณจำเป็นต้องใช้ สำหรับเครื่องผู้ใช้คนเดียวหรือนักพัฒนาซอฟต์แวร์นี่ดูเหมือนจะเป็นการใช้คำสั่งพิเศษโดยไม่จำเป็น

ฉันมักจะได้ยิน / อ่านคนที่เปิด / ร้องเรียนตามแนวของ "ฉันเป็นคนเดียวที่ใช้ระบบนี้ดังนั้นฉันไม่ควรต้องใช้sudoและป้อนรหัสผ่าน" สำหรับผู้อ่านที่มีมุมมองดังกล่าวและเนื่องจากเป็นสิ่งที่เกี่ยวข้องที่นี่เราจะเตือนตนเองเกี่ยวกับเหตุผลด้านความปลอดภัยขั้นพื้นฐานสำหรับการรูทเพื่อเป็นเจ้าของสิ่งต่าง ๆ

ไฟล์โปรแกรมส่วนใหญ่ที่ติดตั้งบนระบบอูบุนตูมีโหมดไฟล์ 755 หรือในสัญลักษณ์สัญลักษณ์rwxr-xr-xซึ่งหมายความว่าผู้ใช้หรือโปรแกรมใด ๆ สามารถดำเนินการได้แต่เฉพาะเจ้าของไฟล์รูทเท่านั้นที่สามารถแก้ไขได้ (ในทางเทคนิคสิ่งนี้ยังกำหนดให้ไม่มีใครนอกจากรูทต้องได้wรับอนุญาตในไดเรกทอรีที่มีพวกมันดังนั้นผู้ใช้รายอื่นไม่สามารถลบหรือย้ายมันได้)

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

หากคุณchown /usr/local, ใด ๆโปรแกรมการทำงานที่มีสิทธิ์ของคุณสามารถเขียนไฟล์ที่นั่นซึ่งอาจต่อมาได้รับการดำเนินการเป็นรากด้วยเหตุผลบางอย่างเช่นโดยการแทนที่คำสั่งที่มีชื่อเดียวกันอีก /usr/local/binอยู่ในค่าเริ่มต้น$PATHและsudoเป็นsecure_pathและจะมาก่อนสถานที่อื่น ๆ ในทั้งสอง ดังนั้นถ้าฉันมีสอง executables

/usr/local/bin/chown
/bin/chown

เมื่อฉันรันsudo chown ..., ในจะถูกดำเนินการchown/usr/local/bin

แต่คุณอาจรู้ทุกอย่างแล้วเนื่องจากเหตุผลข้อที่สองของคุณเกี่ยวกับความปลอดภัย:

นอกจากนี้ซอฟแวร์ถ้าคุณได้รวบรวมไว้ในเครื่องเพื่อติดตั้ง/usr/localซอฟแวร์ในปัจจุบันความต้องการของรากที่จะแก้ไขตัวเองหรือติดตั้งปลั๊กอิน ดูเหมือนว่าไม่ปลอดภัย - ฉันต้องการใช้เฉพาะsudoเมื่อฉันรู้ว่าจะเกิดอะไรขึ้นเท่านั้น

ในกรณีที่จำเป็นต้องพูดถึงสิ่งนี้ที่นี่มันถูกต้องอย่างแน่นอน (ตาม FHS ต่อไป) เพื่อติดตั้งซอฟต์แวร์ที่คอมไพล์/usr/localแล้ว แต่การรวบรวมตัวเองควรจะทำที่ไหนสักแห่งในของคุณ$HOMEโดยไม่ต้องsudoจนกว่าขั้นตอนสุดท้ายเมื่อคุณพิมพ์sudo make installหรือเทียบเท่า

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

สิ่งนี้อาจมีประโยชน์ ความหมายคือคุณเชื่อถือโปรแกรมที่จะทำสิ่งที่ชอบภายใน/usr/localแต่ไม่ได้ที่อื่น หากมันร้องขอการยกระดับสิทธิ์คุณสามารถปฏิเสธที่จะอนุญาตให้อัปเดตหรือถอนการติดตั้ง นั่นทำให้ฉันรู้สึกบางอย่าง แต่ฉันคิดว่าการพยายามใช้/usr/localแซนด์บ็อกซ์แบบนี้อาจไม่ใช่ความคิดที่ดีหรืออย่างน้อยก็ไม่น่าจะเป็นทางออกที่ปลอดภัยที่สุด มันไม่ใช่ตำแหน่งที่แยกอย่างเหมาะสม (แยกได้/optเล็กน้อยกว่าเนื่องจากไม่ใช่ค่าเริ่มต้น$PATH) โปรแกรมอาจเขียนหรือลบบางสิ่ง/usr/localเพื่อทำให้เกิดความเสียหาย โปรแกรมอื่น ๆ (ที่เขียนได้ไม่ดี) ที่คุณเรียกใช้อาจเขียนและรันโค้ดที่คุณไม่ทราบ

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


6

มันเป็นเรื่องปกติที่ไม่ได้เป็นเจ้าของ/usr/local rootแต่คุณสามารถเปลี่ยนเจ้าของได้ตามที่คุณต้องการ

แต่ฉันแนะนำเพื่อให้แน่ใจว่า/usr/local/sbinยังคงเป็นของrootเพื่อหลีกเลี่ยงปัญหาความปลอดภัย คำสั่งที่นี่มักถูกเรียกใช้โดยรูทเท่านั้น


2
ฉันทำการติดตั้ง bower ก่อนหน้านี้และแบบฝึกหัดแนะนำให้ทำ chown -R $ USER / usr / local ดังนั้นตอนนี้ฉันกำลังเรียกใช้ chown -R root / usr / local / sbin - มีโฟลเดอร์อื่น ๆ ใน / usr / local ที่จะ จะดีกว่าด้วยความเป็นเจ้าของรูต? ฉันควรตรวจสอบการอนุญาตทั้งหมดก่อนรันคำสั่ง "เสียใจเมื่อกลับมาทันที"
OnethingSimple

2
คำตอบนี้ไม่น่าพอใจและคำอธิบายนั้นไม่ถูกต้องจริงๆ หากด้วยเหตุผลด้านความปลอดภัยจำเป็นต้องให้รูทคำสั่งไว้วางใจรูทเป็นเจ้าของสิ่งที่เกี่ยวกับคำสั่งใน/usr/local/binรูทนั้น (และผู้ใช้อื่น ๆ ) อาจทำงานได้ พวกเขาจะไม่ต้องเป็นเจ้าของโดย root หรือไม่? นอกจากนี้คำสั่งการใช้ราก - รวมทั้งคำสั่งใน/usr/local/sbin--may /usr/local/libขึ้นอยู่กับห้องสมุดสาธารณะใน การเปลี่ยนไลบรารี่เหล่านี้สามารถแนะนำการเปลี่ยนแปลงโดยพลการของคำสั่งที่ใช้งานได้ การยืนกรานว่า/usr/local/sbinรากยังคงเป็นของรากอยู่โดยพลการ
Eliah Kagan

5

สำหรับซอฟต์แวร์เท่านั้นคุณ/usr/localจำเป็นต้องใช้ไดเรกทอรีบ้านของคุณแทน

แทนการเปลี่ยนกรรมสิทธิ์ของหรือมีการเรียกใช้คำสั่งเป็นรากเมื่อคุณไม่ต้องการที่จะคุณก็ควรกำหนดค่าสร้างของคุณเพื่อให้พวกเขาติดตั้งในไดเรกทอรีบ้านของคุณแทน/usr/local /usr/localสิ่งนี้จะจัดการปัญหาที่อาจเกิดขึ้นทั้งหมดด้วยการเปลี่ยนความเป็นเจ้าของ/usr/localรวมถึงวิธีการbinและsbinไดเรกทอรีย่อยที่อยู่ในrootเส้นทางของ

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

ด้วยการติดตั้งซอฟต์แวร์ในไดเรกทอรีบ้านของคุณไบนารีที่จะมีในหายไปแทนจะไปใน/usr/local/bin คุณจะได้รับไดเรกทอรีย่อยอื่น ๆ ของไดเรกทอรีบ้านของคุณที่สอดคล้องกับไดเรกทอรีย่อยของซอฟต์แวร์ที่คุณติดตั้งความต้องการ โดยทั่วไปจะเกิดขึ้นโดยอัตโนมัติเมื่อคุณติดตั้งซอฟต์แวร์จากซอร์สโค้ด/home/username/bin/usr/local

การกำหนดค่า Builds ของคุณ

ซอฟต์แวร์ส่วนใหญ่ที่คุณสร้างจากซอร์สโค้ดมีขั้นตอนในการรัน:

./configure

สำหรับซอฟต์แวร์ส่วนใหญ่ที่มาพร้อมกับconfigureสคริปต์ที่สามารถเรียกใช้เช่นนั้นจะมีค่าเริ่มต้นในการกำหนดค่าบิลด์สำหรับการติดตั้งภายใน/usr/localเมื่อคุณรันsudo make installเพื่อติดตั้งในที่สุด เหตุผลก็คือมันเทียบเท่ากับการทำงานโดยปริยาย:

./configure --prefix=/usr/local

ในการกำหนดค่าบิลด์สำหรับการติดตั้งในโฮมไดเร็กทอรีของคุณให้ใช้สิ่งนี้แทน:

./configure --prefix="$HOME"

ในทางปฏิบัติใน Ubuntu เส้นทางไดเรกทอรีหลักไม่มีช่องว่างช่องว่างอื่น ๆ หรืออักขระอื่น ๆ ที่เชลล์จะได้รับการดูแลเป็นพิเศษ*ดังนั้นหากคุณไม่ได้ตั้งค่าบัญชีผู้ใช้ของคุณค่อนข้างแปลกคุณสามารถพิมพ์:

./configure --prefix=$HOME

(ฉันไม่แนะนำให้ใช้นิสัยนี้ในการเขียนสคริปต์นอกจากนี้ในระบบปฏิบัติการอื่น ๆ - เช่น macOS - เป็นเรื่องแปลกสำหรับพา ธ ไปยังโฮมไดเร็กตอรี่ของผู้ใช้เพื่อให้มีช่องว่าง)

หรือหากคุณต้องการคุณสามารถพิมพ์พา ธ โฮมไดเร็กตอรี่แบบเต็มได้:

./configure --prefix=/home/username

(แทนที่usernameด้วยชื่อผู้ใช้จริงของคุณแน่นอนถ้าด้วยเหตุผลบางประการไดเรกทอรีบ้านของคุณไม่ได้อยู่ใน/homeนั้นคุณจะต้องปรับเปลี่ยนตามลำดับ)

การติดตั้ง Builds ของคุณ

หลังจากที่คุณเรียกmakeคุณอาจจะคุ้นเคยกับการทำงานsudo make installแต่เมื่อคุณติดตั้งในไดเรกทอรีบ้านของคุณเองคุณไม่จำเป็นต้องเรียกใช้มันเป็นรากเพื่อให้คุณสามารถ - และควรsudo --omit เพิ่งรัน:

make install

ในทำนองเดียวกันสำหรับซอฟต์แวร์ที่รองรับuninstallเป้าหมาย:

make uninstall

ตรงนี้เป็นสิ่งที่คุณขอ ... /usr/localเพียงแค่ในไดเรกทอรีบ้านของคุณไม่ได้

เรียกใช้โปรแกรมของคุณ

อาจเป็นbinไดเรกทอรีย่อยของโฮมไดเร็กตอรี่ของคุณ:

  • แล้วในของคุณ$PATH, หรือ
  • จะอยู่ในของคุณ$PATHถ้าคุณเพิ่งออกจากระบบและกลับเข้ามาใหม่

เหตุผลก็คือ.profileไฟล์ในโฮมไดเร็กตอรี่ของคุณ, ซึ่งมีคำสั่งที่ทำงานเมื่อคุณเข้าสู่ระบบ, ประกอบด้วยสิ่งนี้ตามค่าเริ่มต้นสำหรับบัญชีผู้ใช้ที่สร้างในUbuntu เวอร์ชันส่วนใหญ่ (รวมถึงบัญชีผู้ดูแลระบบเริ่มต้นที่สร้างขึ้นเมื่อคุณติดตั้งระบบปฏิบัติการ):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

รหัสนั้นจะทำงานเมื่อคุณเข้าสู่ระบบ (เพราะมันอยู่ใน.profile) และวางbinไดเรกทอรีส่วนบุคคลของคุณใน$PATH กรณีที่มันมีอยู่ในเวลานั้น นั่นเป็นเหตุผลที่คุณอาจต้องออกจากระบบและกลับเข้ามาใหม่

รุ่นเก่าเช่น Ubuntu 14.04 รวมถึงรุ่นใหม่กว่าเช่น Ubuntu 17.10 มาพร้อมกับสิ่งนั้น อย่างไรก็ตาม Ubuntu 16.04 ซึ่งน่าจะเป็นรุ่นที่ได้รับความนิยมมากที่สุดในขณะนี้มี:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

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

.profileไฟล์ของคุณถูกคัดลอกจาก/etc/skelไดเรกทอรีเมื่อสร้างบัญชีผู้ใช้ของคุณ หากบัญชีผู้ใช้ของคุณถูกสร้างขึ้นใน Ubuntu รุ่นเก่าจะมีรุ่น.profileนั้นและไม่มีการเปลี่ยนแปลง - สำหรับบัญชีผู้ใช้ของคุณ - โดยอัปเกรดเป็นรุ่นล่าสุด

เมื่อbinไดเรกทอรีย่อยของไดเรกทอรีบ้านของคุณอยู่ในของคุณ$PATHคุณจะสามารถเรียกใช้โปรแกรมที่มีแฟ้มที่ปฏิบัติการได้มีการติดตั้งมีเพียงแค่พิมพ์ชื่อของพวกเขาเช่นเดียวกับที่คุณสามารถทำกับโปรแกรมที่ติดตั้งโดยผู้จัดการแพคเกจของ Ubuntu /usr/localหรือภายในติดตั้ง

.localตัวเลือก

คุณอาจจะได้สังเกตเห็นว่าเริ่มต้น.profileไฟล์สำหรับบัญชีผู้ใช้ที่สร้างขึ้นในบางรุ่น Ubuntu รวมทั้งใน 16.04 ตามที่อธิบายไว้ข้างต้นเพิ่มไม่ได้เป็นเพียง$HOME/binเส้นทางของคุณ $HOME/.local/binแต่ยัง หากคุณ.profileไม่ได้เพิ่มสิ่งนั้น แต่คุณต้องการคุณสามารถแก้ไขได้

แม้ว่ามักจะใช้เพื่อจัดเก็บการตั้งค่าและข้อมูลแคชคุณยังสามารถติดตั้งซอฟต์แวร์ใน.localไดเรกทอรีย่อยของโฮมไดเร็กตอรี่ของคุณ คุณจะรู้สึกไม่ถูกยับยั้งในการทำเช่นนั้นจากการใช้งานและการรักษาความปลอดภัยจุดยืนคล้ายกับ--prefix="$HOME/.local"--prefix="$HOME"

โปรดจำไว้ว่าไฟล์และไดเรกทอรีที่เริ่มต้นด้วย.จะไม่แสดงโดยค่าเริ่มต้นในเบราว์เซอร์ไฟล์กราฟิก (ใช้Ctrl+ Hเพื่อยกเลิกการซ่อนและซ่อนไฟล์ใหม่) หรือโดยlsคำสั่ง (ผ่าน-Aหรือ-aตั้งค่าสถานะเพื่อแสดง) นี่อาจไม่ใช่สิ่งที่คุณต้องการหรืออาจเป็นสิ่งที่คุณต้องการ นี่เป็นเรื่องของการตั้งค่าส่วนตัว

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

คุณอาจจะยังจงใจติดตั้งซอฟต์แวร์บางอย่างใน$HOME/.localและซอฟต์แวร์อื่น ๆ $HOMEใน มันขึ้นอยู่กับคุณ. binไดเรกทอรีใดก็ตามที่ปรากฏขึ้นเป็นอันดับแรกใน$PATHตัวแปรสภาพแวดล้อมของคุณคือไดเรกทอรีที่คำสั่งจะเรียกใช้ในกรณีที่คำสั่งของชื่อเดียวกันมีอยู่ทั้งคู่


เครดิตไปที่ZannaและVideonauthเพื่อชี้ให้เห็นข้อผิดพลาดในคำตอบก่อนหน้านี้ซึ่งเกี่ยวกับ Ubuntu รุ่นใดที่มีรหัสเริ่มต้นใน.profileและช่วยฉันแก้ไข (ดูที่นี่ด้วย )


0

ถ้า sudo นั้นไม่สะดวกให้ทำการอัพเดท / etc / sudoers ดังนั้นคุณไม่จำเป็นต้องใส่รหัสผ่านเมื่อคุณเรียกใช้ sudo ฉันเชื่อว่าเป็นวิธีที่ดีกว่าการเปลี่ยนเจ้าของ / usr / local


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