วิธีตั้งค่า umask บน Linux เพื่อกำหนดสิทธิ์ไฟล์เริ่มต้น

หน้าที่ของ umask บน Linux

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

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

แสดงค่า umask ในเชลล์ที่คุณใช้งานอยู่

umask
umask -S

รูปแบบแรกจะแสดงค่า mask เป็นเลขฐานแปด รูปแบบที่สองจะแสดง mask เดียวกันในรูปแบบสิทธิ์การเข้าถึง ซึ่งเป็นรูปแบบสัญลักษณ์ที่ chmod รองรับ ให้แสดงทั้งสองบรรทัดบนหน้าจอ ข้อมูลทั้งหมดด้านล่างนี้เป็นการเปรียบเทียบกับสิ่งที่เชลล์ของคุณเพิ่งแสดงออกมา

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

สร้างไฟล์และไดเรกทอรี จากนั้นอ่านค่าโหมดกลับมา

cd "$(mktemp -d)"
touch probe.file
mkdir probe.dir
stat -c '%a %A %n' probe.file probe.dir

%a จะแสดงโหมดในรูปแบบเลขฐานแปด และ %A จะแสดงโหมดเดียวกันในรูปแบบ drwxr-xr-x ที่ ls -l ใช้งาน ให้เปรียบเทียบทั้งสองบรรทัดกับ mask ที่คุณเพิ่งพิมพ์ไปก่อนหน้านี้ บิตทุกบิตที่ถูกตั้งค่าไว้ใน mask จะหายไปจากโหมด เพราะการล้างบิตเหล่านั้นเป็นหน้าที่เดียวของ mask หากคอลัมน์ %A ยังอ่านไม่เข้าใจง่ายนัก สตริงสิทธิ์ drwxr-xr-x คือสิ่งที่คุณควรทำความเข้าใจให้ชัดเจนก่อนเป็นอันดับแรก

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

( umask a=rwx; touch open.file; stat -c '%a %A %n' open.file )

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

ไดเรกทอรีเป็นจุดที่บิตเรียกใช้งานที่ถูกล้างไปจะส่งผลกระทบอย่างชัดเจน

( umask a=rw; mkdir noexec.dir; cd noexec.dir )

ในฐานะผู้ใช้ทั่วไป cd จะล้มเหลวด้วยข้อความ bash: cd: noexec.dir: Permission denied เนื่องจาก mask ได้ล้างบิตเรียกใช้งานที่ mkdir ร้องขอไป และไดเรกทอรีที่ไม่มีบิตเรียกใช้งานจะไม่สามารถเข้าถึงได้ root จะข้ามการตรวจสอบนั้นไป ดังนั้นกรณีนี้จึงปรากฏให้เห็นเฉพาะในบัญชีผู้ใช้ปกติเท่านั้น

เหตุใด root และผู้ใช้ของคุณจึงเห็นค่า umask ต่างกัน

ให้รันการวัดค่าเดียวกันผ่านบัญชีอื่นที่เริ่มต้นด้วยวิธีอื่น แล้วเปรียบเทียบผลลัพธ์ทั้งสองรายการที่แสดงอยู่ข้างกัน

umask
sudo -i umask

sudo -i จะเริ่ม login shell ของ root และรันคำสั่ง builtin ภายในนั้น ดังนั้นนี่จึงเป็นบัญชีที่ต่างกันซึ่งเข้าสู่ระบบผ่านเส้นทางการเริ่มต้น (startup path) ที่ต่างกัน บนอิมเมจเซิร์ฟเวอร์มาตรฐานของ Ubuntu และ Debian ทั้งสองบรรทัดอาจแสดงค่าที่ต่างกันได้ ทั้งสองบรรทัดนั้นถูกต้องแล้ว โดยแต่ละบรรทัดจะแสดงสิ่งที่เส้นทางการเริ่มต้นของตนเองสร้างขึ้น และเนื้อหาที่เหลือของโพสต์นี้จะกล่าวถึงส่วนประกอบของระบบที่สร้างค่าเหล่านั้นขึ้นมา

ไฟล์ใดบนอิมเมจของคุณที่เป็นตัวกำหนดค่านี้

grep -nE '^(UMASK|USERGROUPS_ENAB)' /etc/login.defs
grep -rn pam_umask /etc/pam.d/
grep -rn umask /etc/profile /etc/profile.d/ /etc/bash.bashrc ~/.profile ~/.bashrc 2>/dev/null || echo 'no umask line in the shell startup files'

หากคำสั่ง grep แรกไม่แสดงผลลัพธ์ใดๆ ให้รันคำสั่งอีกครั้งโดยไม่ต้องใช้ anchor ^ เนื่องจากบรรทัดนั้นอาจถูก comment ไว้ และบรรทัดที่ถูก comment ถือเป็นเอกสารประกอบไม่ใช่การตั้งค่า คำสั่ง grep ที่สามเป็นคำสั่งที่มักทำให้ผู้ใช้ประหลาดใจ บน Debian และ Ubuntu ไฟล์ /etc/profile ที่มากับระบบส่วนใหญ่จะชี้ไปที่ PAM แทนที่จะกำหนดค่า mask ด้วยตัวเอง ดังนั้นไฟล์ที่คุณคาดว่าเป็นตัวควบคุมจึงมักไม่ใช่ตัวที่ทำงานจริง grep จะส่งค่า exit code ที่ไม่ใช่ศูนย์เมื่อไม่พบสิ่งที่ค้นหา ซึ่งเป็นเหตุผลว่าทำไมบรรทัดนั้นจึงลงท้ายด้วย || echo ในอิมเมจที่ไม่มีไฟล์เริ่มต้นใดระบุถึง mask คุณจะได้รับข้อความแจ้งเตือนแทนที่จะเงียบหายไป และข้อความนั้นคือผลลัพธ์ที่คุณค้นหา

/etc/login.defs ประกาศค่าหนึ่งไว้ แต่ PAM บังคับใช้อีกค่าหนึ่ง

บรรทัด UMASK ใน /etc/login.defs คือค่าที่คู่มือส่วนใหญ่อ้างถึง ทั้ง kernel และ shell ไม่ได้อ่านไฟล์ดังกล่าว แต่ไฟล์นี้ถูกอ่านโดย pam_umask ซึ่งเป็นโมดูล PAM (pluggable authentication modules) ที่ทำงานเมื่อมีการสร้าง session ขึ้นมา pam_umask จะเลือกใช้ค่าแรกที่พบตามลำดับดังนี้: รายการ umask= ในฟิลด์ GECOS ของผู้ใช้, อาร์กิวเมนต์ umask= ที่เขียนไว้ในบรรทัด pam_umask.so เอง และสุดท้ายคือ UMASK จาก /etc/login.defs แต่ละ distribution อาจมีการปรับแต่งโมดูลนี้ ดังนั้นให้รัน man pam_umask บน image ของคุณเพื่อดูลำดับที่แสดงผลออกมา

นี่คือสาเหตุที่ /etc/login.defs อาจประกาศค่าหนึ่งไว้ ในขณะที่ session ของคุณกลับได้อีกค่าหนึ่งโดยไม่มีการแจ้งเตือนใดๆ ทั้งสิ้น การใช้ grep จะช่วยให้คุณทราบว่าคุณอยู่ในกรณีใด หากบรรทัด pam_umask.so มีอาร์กิวเมนต์ umask= ของตัวเอง ค่าใน login.defs ก็จะถูกละเลยไป

USERGROUPS_ENAB และข้อยกเว้นสำหรับ root

id -un
id -gn

หากคำสั่งทั้งสองแสดงชื่อเดียวกัน แสดงว่าคุณกำลังใช้ user private group ซึ่งหมายความว่าบัญชีผู้ใช้นั้นถูกสร้างขึ้นพร้อมกับกลุ่มที่มีชื่อเดียวกับชื่อบัญชี โมดูล pam_umask มีพฤติกรรมแบบ usergroups ซึ่งควบคุมโดย USERGROUPS_ENAB ในไฟล์ /etc/login.defs เมื่อเปิดใช้งานและบัญชีผู้ใช้นั้นไม่ใช่ root รวมถึงชื่อกลุ่มหลักตรงกับชื่อผู้ใช้ โมดูลจะคัดลอกตัวเลขหลักเจ้าของ (owner digit) ของ umask ไปไว้ในหลักกลุ่ม (group digit) ส่งผลให้ session นั้นสิ้นสุดลงด้วยค่า mask ที่เปิดสิทธิ์การเขียนสำหรับกลุ่มให้กับทุกไฟล์ที่บัญชีนั้นสร้างขึ้น ทั้งนี้ root จะถูกยกเว้นโดยตัวโมดูลเอง และการยกเว้นนี้เป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ shell สองตัวบนเซิร์ฟเวอร์เดียวกันแสดงค่า mask ที่แตกต่างกัน

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

Login shell, non-login shell และ non-interactive shell

umask
bash -lc 'umask'
bash -c 'umask'

PAM จะทำงานเมื่อมีการสร้าง session ขึ้นมา เช่น login บนคอนโซล, sshd, su และ sudo -i แต่ PAM จะไม่ทำงานเมื่อ shell หนึ่งเริ่มการทำงานของอีก shell หนึ่ง bash -l เป็น login shell จึงอ่านไฟล์ /etc/profile และ ~/.profile แต่จะไม่เรียกใช้ pam_umask เนื่องจากไม่มีการสร้าง session ใหม่เกิดขึ้น ส่วน bash -c จะไม่อ่านไฟล์ทั้งสองและจะสืบทอดค่า mask มาจาก process ที่เรียกใช้งานมัน งาน cron job, git hook และโปรแกรมที่เริ่มโดย service manager ทั้งหมดล้วนอยู่ในกรณีหลังนี้ ดังนั้นค่า mask ของโปรแกรมเหล่านี้จึงเป็นค่าเดียวกับที่ process แม่มีอยู่

นี่คือเหตุผลว่าทำไมรายงานปัญหาที่ว่า "ฉันตั้งค่าใน /etc/profile แล้วแต่ service ยังคงเขียนไฟล์ด้วยโหมดที่ไม่ถูกต้อง" จึงพบได้บ่อย เพราะ service ไม่เคยอ่านไฟล์ดังกล่าวเลย

การตั้งค่าให้มีผลถาวร

ให้ตั้งค่า umask ในจุดที่เวิร์กโหลดเริ่มต้นทำงานจริง เนื่องจากแต่ละเส้นทางการเริ่มต้นจะอ่านไฟล์การตั้งค่าที่แตกต่างกัน

1. สำหรับบัญชีผู้ใช้ที่มีการล็อกอิน: ใช้ UMASK ในไฟล์ /etc/login.defs ซึ่งจะถูกนำไปใช้โดย pam_umask กับทุกเซสชันบนเครื่อง การตั้งค่านี้มีผลทั้งเครื่อง จึงส่งผลต่อทุกบัญชีพร้อมกัน
2. สำหรับบัญชีผู้ใช้รายบุคคล: อาร์กิวเมนต์ umask= ในบรรทัด pam_umask.so มีผลทั้งเครื่องเช่นกัน ดังนั้นการตั้งค่าเฉพาะผู้ใช้ควรทำในฟิลด์ GECOS ของผู้ใช้นั้น หรือในไฟล์ ~/.profile สำหรับ login shell และไฟล์ ~/.bashrc สำหรับ interactive shell
3. สำหรับ daemon ที่ทำงานภายใต้ systemd: ใช้ UMask= ในส่วน [Service] ของ unit ไฟล์ เนื่องจาก unit ถูกเริ่มโดย service manager ทำให้ไฟล์ /etc/profile ไม่ถูกอ่านและ pam_umask ไม่ทำงาน unit ไฟล์จึงเป็นจุดเดียวที่ส่งผลต่อ daemon โดยตรง
4. สำหรับสคริปต์ที่เริ่มโดย cron หรือ hook: ให้ระบุคำสั่ง umask ไว้ที่บรรทัดแรกของสคริปต์ ก่อนที่สคริปต์จะสร้างไฟล์หรือไดเรกทอรีใดๆ

[Service]
UMask=<the octal mask you chose>

จากนั้นให้ตรวจสอบผลลัพธ์จากการเริ่มทำงานใหม่ผ่านเส้นทางเดิมเสมอ ห้ามตรวจสอบจาก shell ที่คุณใช้แก้ไขไฟล์ เพราะ shell ปัจจุบันได้โหลดค่า mask ไปแล้ว และการแก้ไขไฟล์คอนฟิกจะไม่ย้อนกลับไปเปลี่ยนค่าในกระบวนการที่กำลังทำงานอยู่

bash -lc 'umask'
sudo -i umask

เหตุใดการใช้ chmod ในภายหลังจึงไม่ใช่การแก้ไขที่ถูกต้อง

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

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

ให้กำหนดโหมดตั้งแต่ตอนสร้างไฟล์แทน install -m u=rw,go= newfile /etc/app/newfile จะเขียนไฟล์ปลายทางด้วยโหมดที่ระบุไว้อย่างชัดเจน และ mkdir -m ก็ทำเช่นเดียวกันสำหรับไดเรกทอรี ทั้งสองคำสั่งจะใช้โหมดที่คุณกำหนดและเพิกเฉยต่อค่า umask ssh-keygen จะตั้งค่าโหมดให้กับ private key ที่มันเขียนขึ้น ซึ่งเป็นเหตุผลว่าทำไมไฟล์นั้นมักจะถูกต้องบนเครื่องที่ไฟล์อื่นๆ ไม่ถูกต้อง

สิ่งที่มักจะได้รับผลกระทบคือ SSH ไฟล์ ~/.ssh ที่สร้างด้วย mkdir ปกติ หรือไฟล์ authorized_keys ที่เพิ่มข้อมูลด้วย cat >> จะใช้ค่า umask ของ shell ของคุณ เมื่อเปิดใช้งาน StrictModes ตัว sshd จะปฏิเสธการอ่านไฟล์ key จากไดเรกทอรีที่กลุ่มอื่นสามารถเขียนได้ ฝั่งไคลเอนต์จะได้รับข้อความ Permission denied (publickey) ในขณะที่ /var/log/auth.log ของเซิร์ฟเวอร์จะบันทึกสาเหตุที่แท้จริงไว้:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

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

การคัดลอกและจัดเก็บถาวรจะเพิกเฉยต่อ mask

cp -p และ rsync -a จะกู้คืนโหมดที่บันทึกไว้บนไฟล์ต้นฉบับ ดังนั้น mask จึงไม่มีผลต่อผลลัพธ์ที่ได้ tar จะดำเนินการในลักษณะเดียวกันเมื่อทำการแตกไฟล์ในฐานะ root หรือในฐานะผู้ใช้ทั่วไปที่ใช้ -p ไฟล์ที่กู้คืนจากข้อมูลสำรองจะคงโหมดเดิมที่มีอยู่ ณ ขณะที่ทำการสำรองข้อมูลนั้นไว้ โปรดตรวจสอบประเด็นนี้ก่อนที่จะสรุปว่า mask ที่ถูกต้องกำลังถูกเพิกเฉย เนื่องจากสำหรับข้อมูลที่กู้คืนมานั้น mask ไม่เคยถูกนำมาพิจารณาตั้งแต่ต้น

FAQ

ทำไม cron job ของฉันถึงสร้างไฟล์ด้วยโหมดที่ต่างจากเซสชัน ssh?

cron job ไม่ใช่ login session ดังนั้น pam_umask จึงไม่ทำงาน และมันไม่ได้อ่านทั้ง /etc/profile หรือ ~/.profile มันจะสืบทอดค่า mask มาจากกระบวนการที่เริ่มต้นมัน ให้ใส่คำสั่ง umask ไว้ที่บรรทัดแรกของสคริปต์ก่อนที่จะมีการสร้างไฟล์ใดๆ และให้สั่งพิมพ์ค่า mask ออกมาหนึ่งครั้งจากภายใน job เพื่อให้คุณเห็นค่าที่แท้จริงของ job นั้น แทนที่จะดูจาก shell ของคุณเอง

ทำไม /etc/login.defs ระบุไว้อย่างหนึ่ง แต่ shell ของฉันแสดงผลอีกอย่างหนึ่ง?

UMASK ใน /etc/login.defs เป็นเพียงค่าสำรองสุดท้ายสำหรับ pam_umask เท่านั้น โมดูลนี้จะให้ความสำคัญกับรายการ umask= ในฟิลด์ GECOS ของผู้ใช้ก่อน ตามด้วยอาร์กิวเมนต์ umask= ในบรรทัด pam_umask.so ภายใน /etc/pam.d/ จากนั้นพฤติกรรม usergroups ซึ่งเปิดใช้งานโดย USERGROUPS_ENAB จะเขียนทับเลขหลักของกลุ่มสำหรับบัญชีที่ไม่ใช่ root หากบัญชีนั้นมีกลุ่มหลักที่ตั้งชื่อตามชื่อบัญชี ให้รัน grep -rn pam_umask /etc/pam.d/ และ id -un; id -gn เพื่อดูว่าเงื่อนไขใดที่ส่งผลต่อบัญชีของคุณ

umask สามารถทำให้ไฟล์เป็น executable ได้หรือไม่?

ไม่ได้ ค่า mask สามารถลบ bit ออกจากสิ่งที่โปรแกรมที่สร้างไฟล์ร้องขอมาได้เท่านั้น touch ไม่เคยร้องขอ execute bit ดังนั้นจึงไม่มี mask ใดที่สร้างไฟล์ executable ได้ ให้ทดสอบในไดเรกทอรีชั่วคราวด้วย ( umask a=rwx; touch f; stat -c '%a %A' f ) หากต้องการ execute bit คุณต้องใช้ chmod หรือโปรแกรมอย่าง install -m ที่ร้องขอ bit ดังกล่าวในขณะสร้างไฟล์

ฉันจะตั้งค่า umask สำหรับ systemd service ได้ที่ไหน?

ให้ตั้งค่าใน unit file โดยใช้ UMask= ภายใต้ส่วน [Service] เนื่องจาก service ถูกเริ่มต้นโดย service manager ไม่ใช่การล็อกอิน ไฟล์เริ่มต้นของ shell จึงไม่ถูกอ่านและ pam_umask ก็ไม่ทำงานสำหรับ service หลังจากรัน systemctl daemon-reload และรีสตาร์ท unit แล้ว ให้ตรวจสอบจากภายนอกโดยปล่อยให้ service สร้างไฟล์ขึ้นมา จากนั้นอ่านผลลัพธ์ด้วย stat -c '%a %n'

ค่า mask เริ่มต้นที่อนุญาตให้กลุ่มเขียนไฟล์ได้นั้นปลอดภัยหรือไม่?

ปลอดภัยตราบเท่าที่กลุ่มนั้นมีสมาชิกเพียงคนเดียว ซึ่งเป็นสมมติฐานเบื้องหลังรูปแบบ user private group หากคุณเพิ่มบัญชีที่สองเข้าไปในกลุ่มนั้น ไฟล์ทุกไฟล์ที่บัญชีแรกสร้างไว้จะถูกเขียนทับโดยสมาชิกใหม่ได้ทันทีโดยไม่ต้องรันคำสั่งใดๆ บนไฟล์เหล่านั้น ให้รัน id -un และ id -gn หากชื่อที่แสดงออกมาเหมือนกัน แสดงว่าคุณกำลังใช้ private group อยู่ หากคุณใช้กลุ่มร่วมกันระหว่างบัญชี ให้ตั้งค่า mask ที่ลบสิทธิ์การเขียนของกลุ่มออก จากนั้นสร้างไฟล์และอ่าน stat -c '%a %n' เพื่อยืนยันว่าการเปลี่ยนแปลงมีผลแล้ว