อิมเมจ Docker ภาษาเกาหลี XWINDOW ที่เชื่อมต่อได้ผ่าน Windows RDP

ขอเผยแพร่อิมเมจ Docker ภาษาเกาหลี XWINDOW (wayland) ที่สร้างขึ้นบน Debian 13 (Trixie) รุ่นล่าสุด

ในความเป็นจริงมีคนใช้ Windows กันเยอะ และบางครั้งก็น่าจะมีช่วงที่อยากเปิดใช้งาน Linux X Window ที่รองรับภาษาเกาหลีผ่าน Docker เพื่อทำงานกันบ้าง
ดังนั้น!
จึงได้ลองสร้างสภาพแวดล้อม GUI ภาษาเกาหลีบน Debian ที่สามารถเข้าถึงได้ผ่าน Windows Remote Desktop ขึ้นมา

ในอิมเมจนี้มีการติดตั้งเครื่องมือหลักที่จำเป็นต่อสภาพแวดล้อมการพัฒนาไว้ล่วงหน้า เช่น Visual Studio Code, Chromium, Vim, Git, Node.js + npm จึงสามารถนำไปใช้เป็นสภาพแวดล้อมสำหรับพัฒนาได้ทันที (จึงทำให้ขนาดค่อนข้างใหญ่เล็กน้อย)

คุณสมบัติหลัก ได้แก่

• รองรับการเชื่อมต่อผ่าน Windows Remote Desktop (RDP)
• เก็บรักษาข้อมูลและวอลุ่ม: หากเชื่อมต่อ /home/(ชื่อผู้ใช้) เป็น Docker volume ก็จะสามารถคงข้อมูลไว้ได้

ข้อควรระวังคือ
เนื่องจากทำงานบน Docker ดังนั้น VSCode และ Chromium จะไม่ใช้โหมด sandbox ขอให้ระมัดระวังด้านความปลอดภัย และฟังก์ชันเสียงถูกตัดออกเนื่องจากมีปัญหาการชนกันและบั๊กอยู่มาก โดยส่วนตัวคิดว่าคนส่วนใหญ่น่าจะฟังเพลงจากเครื่อง Windows PC กันอยู่แล้วจึงตัดออกไว้

เป็นอิมเมจที่มีประโยชน์อย่างยิ่งสำหรับผู้ใช้ภาษาเกาหลีที่ต้องการสร้างสภาพแวดล้อมการพัฒนาได้อย่างรวดเร็ว

ซอร์สอยู่ที่ https://github.com/lancard/x11-korean ลองเข้าไปดูได้ และหากมีฟังก์ชันที่ต้องการก็ส่ง issue หรือ PR มาได้เสมอ!

[chcv0313]

ใน vscode ภายในสามารถสร้างไฟล์ใหม่ได้ แต่แก้ไขไฟล์เดิมไม่ได้ แม้จะเปลี่ยนไฟล์เดิมเป็น chmod 777 แล้วก็ตาม น่าจะเป็นปัญหาเรื่องสิทธิ์หรือความเป็นเจ้าของของกลุ่ม เดี๋ยวจะลองวิธีนั้นวิธีนี้เพิ่มเติมดูครับ

[chcv0313]

ดูเหมือนว่าจะแก้ปัญหาได้โดยแก้ไขไฟล์ sh ที่อยู่ใน entry point และตั้งค่า XWINDOW_USER_ID ให้ตรงกับ ID ของโฟลเดอร์งาน

[chcv0313]

set username

XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "user '$XWINDOW_USER' generated."
fi

ส่วนนี้

XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # ค่าเริ่มต้น 1000
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "user '$XWINDOW_USER' generated with UID $XWINDOW_USER_ID."
else
echo "user '$XWINDOW_USER' already exists."
fi

ผมได้เปลี่ยนเป็นแบบนี้ แล้วกำหนด USER_ID ให้ตรงกับ account ID ของเครื่องโฮสต์ครับ

[shakespeares]

ใช้แทน WSL ได้ไหม?

[lancard]

ได้ครับ ใช้งานได้ ผมเองส่วนตัวไม่ค่อยชอบ WSL / WSL2 เลยติดตั้ง docker บน Hyper-V แล้วใช้อันนี้อยู่ครับ

[shakespeares]

ขอถามอย่างระมัดระวังได้ไหมว่ามีเหตุผลอะไรที่คุณไม่ชอบมัน?

[lancard]

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

[doovooda]

เนื้อหาที่คุณพูดถึง ผมเข้าใจได้ไม่ค่อยชัดจากความรู้ที่ผมมีอยู่ เลยอยากถามว่า
มันคล้ายกับโครงสร้างตรรกะพื้นฐานของ WSL หรือ Docker หรือเปล่าครับ?
หรือว่ามีจุดไหนที่ผมเข้าใจผิดไปไหมครับ?

[lancard]

อาจพูดได้ว่า WSL2 ค่อนข้างคล้ายกันอยู่บ้าง แต่โครงสร้างของ WSL ต่างออกไปพอสมควร โดยพื้นฐานแล้วมันทำงานอยู่บนเคอร์เนลของ Windows ส่วน WSL2 แม้จะถูกต้องว่ารันอยู่บนไฮเปอร์ไวเซอร์ แต่ผมคิดว่าระดับการแยกยังต่างกันเล็กน้อย เพราะมีการทำ auto mount ทั้งสองฝั่ง ทำให้แต่ละ OS เข้าถึงระบบไฟล์ของอีกฝั่งได้ ซึ่งอาจทำให้เกิดผลลัพธ์ที่ไม่พึงประสงค์ได้ เช่น Windows สร้าง $RECYCLE.BIN บน ext4 โดยอัตโนมัติ หรือถ้า OS ฝั่งใดฝั่งหนึ่งถูกแฮ็กเกอร์ยึดได้ ก็อันตรายร้ายแรงต่อทั้งสองฝั่งได้ สิ่งที่ผมทำขึ้นมานั้น ถ้าต้องการก็ไม่ต้อง mount อะไรเลยก็ได้ สามารถให้มันรันอยู่ลำพังโดยไม่เชื่อมกับ Windows ได้
และจะบอกว่าความเร็วในการติดตั้งก็มีผลด้วยเหมือนกัน... วิธีแบบ image ของผมก็คือถ้าไม่ชอบก็แค่ลบ docker image ทิ้ง แล้วคัดลอกอันใหม่เพิ่มอีกตัวได้เลย ตอนอัปเดตก็แค่รับ image ใหม่เท่านั้นเอง ผมจำได้ว่าฝั่งเครือข่ายของ WSL2 ก็เคยมีปัญหาอยู่บ้าง นอกจากนี้เคอร์เนลลินุกซ์ก็ไม่ใช่ลินุกซ์เคอร์เนลล้วน ๆ แต่เท่าที่ทราบคือเป็นตัวที่ MS ปรับแต่งมา
แนวทางของผมมุ่งไปที่ลินุกซ์ล้วน ๆ (ก็คือต้องการให้แยกจากกัน) เลยค่อนข้างไม่ตรงกับ WSL

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

[doovooda]

เพิ่งมาตรวจสอบครับ
ขอบคุณสำหรับคำตอบที่ใส่ใจมากครับ!

[lancard]

และตัว Docker เองก็แทบจะเป็น Linux only อยู่แล้ว อีกทั้งการรัน Docker บน NAS เรื่องการแยกตัวพิมพ์ใหญ่/เล็ก และการทำงานผ่าน Docker ก็มีข้อดีหลายอย่าง จึงมองได้ว่าเป็นสิ่งที่ทำขึ้นด้วยเหตุผลเหล่านี้ครับ

[lancard]

ในกรณีของ privileged mode ได้แก้ไขให้ทำงานใน sandbox แล้ว ในกรณีของ privileged mode สามารถเชื่อมต่อ local resource (ไดรฟ์ C เป็นต้น) ได้ โดยจะเมานต์การเชื่อมต่อไว้ที่ $HOME/thinclient_drives

[lancard]

หากต้องการเชื่อมต่อทรัพยากรภายในเครื่อง (เช่น C: D: เป็นต้น) ให้รันในโหมด privileged ได้เลยครับ (แล้วการคัดลอกไฟล์ด้วย CTRL + C / V จะใช้งานได้)

[po5678]

โอ๊ะ... ดูเหมือนว่า VS Code จะรันไม่ได้เลยนะ :)

[po5678]

ตอบเองครับ เพราะไม่มีใครตอบ เลยลองโน่นลองนี่ดู แล้วพบว่าเปิดได้เมื่อรัน code --no-sandbox ในเทอร์มินัล

[lancard]

อืม? หรือว่าของที่อยู่บนเดสก์ท็อปเปิดไม่ได้เหรอครับ?

[po5678]

อ๋อ ครับ ใช้งานไม่ได้จริงๆ ไม่แน่ใจว่าผมทำอะไรผิดไป..

[lancard]

ผมยังคงปรับเปลี่ยนอิมเมจอยู่เรื่อย ๆ เลยอาจมองว่าเป็นอิมเมจระหว่างทางก็ได้ครับ
อย่างแรก ลองตรวจสอบก่อนว่าไอคอน vscode บนเดสก์ท็อปตั้งคำสั่งเป็น /usr/bin/code %F หรือไม่
แล้วเปิดไฟล์ /usr/bin/code ขึ้นมา แล้วตรวจสอบว่าบรรทัดรองสุดท้ายเป็น
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"
หรือไม่ครับ

[chcv0313]

ช่วงนี้กำลังศึกษาการใช้ Docker อยู่ครับ ลองใช้ trivy ตรวจหาช่องโหว่ของอิมเมจนี้แล้วพบว่ามีช่องโหว่ 1,053 รายการ ดูเหมือนไม่น่าจะสำคัญทั้งหมดและเหมือนจะตรวจเจอทุกอย่างไปหมด เลยอยากขอคำแนะนำหน่อยครับว่าในทางปฏิบัติแล้วควรตรวจสอบและทำให้อิมเมจมีความปลอดภัยอย่างไร

[lancard]

จริง ๆ แล้วมีวิธีจัดการช่องโหว่มากมายจนไม่มีคำตอบที่ตายตัว
ในกรณีของผมจะใช้เวอร์ชันล่าสุดที่เสถียรที่สุดเท่าที่จะทำได้ และเมื่อใช้ GitHub Actions ก็จะเปิดใช้ security bot ให้มากที่สุดเท่าที่ทำได้ จริง ๆ แล้วอย่างที่เห็นกันว่าอิมเมจ xwindow ตัวนี้ไม่มีส่วนที่เขียนโปรแกรมไว้ จึงน่าจะมีเพียงช่องโหว่พื้นฐานของตัวโปรแกรมที่ติดตั้งมาเท่านั้น

[grollcake]

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

[lancard]

เท่าที่ผมทราบ ไม่ว่าจะเป็นบน Windows หรือ Linux, Chrome จะทำงานในโหมด sandbox อยู่แล้ว ดังนั้น... ต่อให้มีการสร้าง exploit ผ่าน JavaScript เป็นต้นเพื่อโจมตีช่องโหว่ ก็จะไม่ส่งผลกระทบต่อ OS จริงโดยตรง

แต่ในโหมดคอนเทนเนอร์ น่าจะต้องเปิดโหมด privileged ก่อนถึงจะเปิดใช้ฟังก์ชันนั้นได้

แน่นอนว่าอาจจะแนะนำให้เปิดโหมดนั้นก็ได้ แต่ผมมองว่าตัวคอนเทนเนอร์เองก็เป็น sandbox อยู่แล้ว เหมือนหน้าต่างที่เปิดปิดได้ง่าย ๆ อะไรทำนองนั้น...

เพราะแบบนั้น Chromium และ VS Code ที่พัฒนาบน Electron จึงถูกตั้งให้รันในโหมดที่ไม่ใช่ sandbox

ทั้งหมดนี้หมายความว่า ถ้าสมมติว่า Chromium กับ VS Code มีช่องโหว่ และผู้โจมตีสามารถใช้มันสร้าง exploit ได้ ก็อาจจะมีความเสี่ยงครับ

[lancard]

ชื่อ docker คือ lancard/xwindow-korean

[lancard]

เนื่องจากเป็น wayland จึงได้เปลี่ยนชื่อ repo เป็น https://github.com/lancard/xwindow-korean ครับ~

[lancard]

เนื่องจาก Ubuntu อยู่ในตระกูล Debian จึงสามารถใช้งาน apt และเครื่องมืออื่น ๆ ได้อย่างสะดวกเช่นกัน พอได้ลองใช้แล้ว Debian ดูจะดีกว่าอิมเมจพื้นฐานของ Ubuntu ครับ