Linux-ல் umask என்றால் என்ன? அதன் செயல்பாட்டை அறிவது

Linux-ல் umask-ன் செயல்பாடு

Linux-ல் இயங்கும் ஒவ்வொரு process-உம் ஒரு umask எண்ணைக் கொண்டிருக்கும். அந்த process உருவாக்கும் ஒவ்வொரு file மற்றும் directory-ன் mode-ஐ இதுவே தீர்மானிக்கிறது. ஒரு program உருவாக்கப்படும்போது, தனக்குத் தேவையான permissions-ஐ kernel-இடம் கேட்கும். அந்த mask-ல் குறிப்பிடப்பட்டுள்ள ஒவ்வொரு bit-ஐயும் kernel நீக்கிவிட்டு, மீதமுள்ளவற்றை மட்டும் அமல்படுத்தும். umask ஒருபோதும் access-ஐ வழங்குவதில்லை. உருவாக்கும் program கேட்ட permissions-லிருந்து சில bits-ஐ இது நீக்குகிறது.

இந்த மதிப்பு உங்கள் distribution-ன் பண்பு அல்ல. நீங்கள் எந்த account-ல் இருக்கிறீர்கள் மற்றும் shell எவ்வாறு தொடங்கப்பட்டது என்பதைப் பொறுத்தே இது அமையும். ஒரே machine-ல், ஒரே நேரத்தில், ஒரு stock image-ல் கூட இந்த இரண்டு காரணிகளும் மாறுபடலாம். எனவே, முதல் படி manual-ஐப் பார்ப்பது அல்ல. உங்கள் முன்னால் உள்ள machine-ல் அதன் மதிப்பை அளவிடுவதே ஆகும்.

தற்போதைய shell-ல் umask-ஐ அச்சிடுதல்

umask
umask -S

முதல் வடிவம் mask-ஐ octal முறையில் அச்சிடுகிறது. இரண்டாவது வடிவம், அதே mask-ஐ chmod ஏற்கும் symbolic வடிவில், அது அனுமதிக்கும் permissions-ஆக அச்சிடுகிறது. இரண்டு வரிகளையும் திரையில் வைத்திருக்கவும். கீழே உள்ள அனைத்தும் உங்கள் shell அச்சிட்டவற்றுடன் ஒப்பிடுவதற்கானவை.

umask என்பது shell builtin ஆகும், இது வட்டில் உள்ள ஒரு program அல்ல. இதை type umask மூலம் உறுதிப்படுத்தவும். இது முக்கியமானது, ஏனெனில் ஒரு builtin, shell process-ஐயே மாற்றுகிறது. ஒரு தனி program தனது சொந்த process-ஐ மட்டுமே மாற்ற முடியும், பின்னர் அது வெளியேறும்போது அந்த மாற்றமும் நீங்கிவிடும்.

ஒரு கோப்பு மற்றும் ஒரு கோப்பகத்தை உருவாக்கி, அவற்றின் முறைகளை (modes) சரிபார்த்தல்

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

%a கட்டளையானது முறையை octal வடிவிலும், %A கட்டளையானது அதே முறையை drwxr-xr-x வடிவிலும் அச்சிடுகிறது, இதைத்தான் ls -l பயன்படுத்துகிறது. நீங்கள் சற்று முன்பு அச்சிட்ட mask-உடன் இந்த இரண்டு வரிகளையும் ஒப்பிட்டுப் பாருங்கள். mask-ல் உள்ள ஒவ்வொரு bit-ம் இந்த முறைகளில் விடுபட்டிருக்கும், ஏனெனில் அந்த bit-களை நீக்குவது மட்டுமே mask-ன் பணியாகும். %A நெடுவரிசையைப் புரிந்துகொள்வது கடினமாக இருந்தால், drwxr-xr-x அனுமதி சரம் (permission string) என்பதை முதலில் தெளிவாகப் புரிந்துகொள்வது அவசியம்.

கோப்பும் கோப்பகமும் ஒன்றுக்கொன்று வேறுபடுகின்றன, இந்த வேறுபாட்டிற்கு mask காரணமல்ல. touch கட்டளையானது owner, group மற்றும் other ஆகியோருக்கு read மற்றும் write அனுமதிகளைக் கோருகிறது. mkdir கட்டளையானது அந்த மூன்று தரப்பினருக்கும் read, write மற்றும் execute அனுமதிகளைக் கோருகிறது. ஒரே mask இரண்டு வெவ்வேறு கோரிக்கைகளிலிருந்து கழிக்கப்படுகிறது. எனவே, touch மூலம் உருவாக்கப்பட்ட கோப்பு ஒருபோதும் executable ஆகாது, mask-ல் என்ன இருந்தாலும் சரி: execute bit கோரப்படவே இல்லை, மேலும் ஒரு mask-ஆல் ஒரு bit-ஐ மீண்டும் சேர்க்க முடியாது.

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

அந்த அடைப்புக்குறிகள் கட்டளைகளை ஒரு subshell-ல் இயக்குகின்றன, எனவே அந்த மாற்றம் அந்த shell-உடன் முடிந்துவிடும். இப்போது mask எதையும் நீக்கக் கோருவதில்லை, ஆனாலும் stat அந்த கோப்பில் execute bit இல்லை என்றே காட்டுகிறது. அதன் பிறகு மீண்டும் umask கட்டளையை இயக்கினால், உங்கள் அசல் மதிப்பு மீண்டும் கிடைத்துவிடும். இதிலிருந்து, இந்த அமைப்பு ஒரு process-க்குள் மட்டுமே இயங்குகிறது என்பதும், அது disk-ல் எங்கும் சேமிக்கப்படாமல் child process-களுக்கு மரபுரிமையாகக் கிடைக்கிறது என்பதும் தெளிவாகிறது.

execute bit நீக்கப்பட்டதன் விளைவு கோப்பகங்களில் (directories) தெளிவாகத் தெரியும்.

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

ஒரு சாதாரண பயனராக cd கட்டளையை இயக்கும்போது bash: cd: noexec.dir: Permission denied பிழையுடன் தோல்வியடைகிறது. ஏனெனில், mkdir கோரிய execute bit-ஐ mask நீக்கிவிட்டது, மேலும் execute bit இல்லாத கோப்பகத்திற்குள் நுழைய முடியாது. root பயனர் இந்தச் சோதனையைத் தவிர்த்துவிடுவார், எனவே இது ஒரு சாதாரண கணக்கில் மட்டுமே வெளிப்படும்.

root மற்றும் உங்கள் சொந்த பயனர் ஏன் வெவ்வேறு umask-ஐக் கொண்டுள்ளனர்

மற்றொரு கணக்கின் மூலம் அதே அளவீட்டைச் செய்து, மற்றொரு வழியில் தொடங்கி, இரண்டு வெளியீடுகளையும் அருகருகே வைத்துப் பார்க்கவும்.

umask
sudo -i umask

sudo -i என்பது root-ன் login shell-ஐத் தொடங்கி, அதற்குள் உள்ள builtin கட்டளையை இயக்குகிறது. எனவே, இது வெவ்வேறு தொடக்கப் பாதையின் (startup path) வழியாக வரும் வெவ்வேறு கணக்காகும். பொதுவான Ubuntu மற்றும் Debian server images-ல், இந்த இரண்டு வரிகளும் வெவ்வேறு மதிப்புகளைக் காட்டலாம். இரண்டு வரிகளும் சரியானவைதான். ஒவ்வொன்றும் அதன் சொந்த தொடக்கப் பாதை உருவாக்கியதைக் காட்டுகின்றன. இந்த பதிவின் மீதமுள்ள பகுதி, கணினியின் எந்தப் பகுதி இதை உருவாக்கியது என்பதைப் பற்றியது.

உங்கள் image-ல் எந்தக் கோப்பு அந்த மதிப்பைத் தீர்மானித்தது

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 செய்யப்பட்ட வரி என்பது configuration அல்ல, அது ஒரு ஆவணம் மட்டுமே. மூன்றாவது grep கட்டளைதான் பலரை வியக்க வைக்கும். Debian மற்றும் Ubuntu-வில், வழங்கப்பட்ட /etc/profile பெரும்பாலும் mask-ஐ அமைப்பதற்குப் பதிலாக PAM-ஐயே சுட்டிக்காட்டுகிறது, எனவே நீங்கள் பொறுப்பு என்று நினைத்த கோப்பு உண்மையில் அவ்வாறு இருப்பதில்லை. grep எதையும் கண்டறியாதபோது non-zero status-ஐ வெளியிடும், அதனால்தான் அந்த வரி || echo-ல் முடிகிறது: எந்தவொரு startup கோப்பிலும் mask குறிப்பிடப்படாத image-ல், அமைதிக்கு பதிலாக உங்களுக்கு அந்தச் செய்தி கிடைக்கும், அந்தச் செய்தியே நீங்கள் கண்டறிந்த முடிவாகும்.

/etc/login.defs ஒரு மதிப்பை விளம்பரப்படுத்துகிறது, ஆனால் PAM வேறொன்றைப் பயன்படுத்துகிறது

/etc/login.defs-ல் உள்ள UMASK வரிதான் பெரும்பாலான வழிகாட்டிகளில் குறிப்பிடப்படும் மதிப்பாகும். கர்னலோ அல்லது ஷெல்லோ இந்த கோப்பை வாசிப்பதில்லை. ஒரு session உருவாக்கப்படும்போது இயங்கும் PAM (pluggable authentication modules) தொகுதியான pam_umask மூலம் இது வாசிக்கப்படுகிறது. pam_umask அது கண்டறியும் முதல் மதிப்பை எடுத்துக்கொள்ளும்: பயனரின் GECOS புலத்தில் உள்ள umask= பதிவு, பிறகு pam_umask.so வரியிலேயே எழுதப்பட்ட umask= ஆர்குமெண்ட், இறுதியாக /etc/login.defs-லிருந்து UMASK. விநியோகங்கள் (distributions) இந்த தொகுதியை patch செய்வதால், உங்கள் சொந்த image-ல் man pam_umask கட்டளையை இயக்கி, அங்கு அச்சிடப்பட்ட வரிசையைச் சரிபார்க்கவும்.

இதன் காரணமாகவே /etc/login.defs ஒரு மதிப்பை விளம்பரப்படுத்தினாலும், உங்கள் session வேறொரு மதிப்பை முடிவாகப் பெறுகிறது; இது குறித்து எந்த எச்சரிக்கையும் அச்சிடப்படுவதில்லை. நீங்கள் எந்த நிலையில் இருக்கிறீர்கள் என்பதை grep கட்டளைகள் உங்களுக்குத் தெரிவிக்கும். pam_umask.so வரியில் அதன் சொந்த umask= ஆர்குமெண்ட் இருந்தால், login.defs வரியின் மதிப்பு புறக்கணிக்கப்படும்.

USERGROUPS_ENAB மற்றும் root விதிவிலக்கு

id -un
id -gn

இவை இரண்டும் ஒரே பெயரை அச்சிட்டால், உங்களிடம் user private group உள்ளது என்று அர்த்தம்: அந்த account உருவாக்கப்பட்டபோது, அதன் பெயரிலேயே ஒரு group-ம் உருவாக்கப்பட்டுள்ளது. pam_umask-ல் usergroups என்ற செயல்பாடு உள்ளது, இது /etc/login.defs-ல் உள்ள USERGROUPS_ENAB மூலம் கட்டுப்படுத்தப்படுகிறது. இது செயல்பாட்டில் இருக்கும்போது, account root ஆக இல்லாமலும், primary group பெயர் user பெயருடன் ஒத்துப்போனாலும், இந்த module mask-ன் owner இலக்கத்தை group இலக்கத்திற்கு நகலெடுக்கும். அந்த account உருவாக்கும் அனைத்து கோப்புகளிலும் group bits திறந்திருக்கும் வகையில் session முடிவடையும். Root பயனர் இந்த module-ஆல் விலக்கப்பட்டுள்ளார்; ஒரே server-ல் இரண்டு shells வெவ்வேறு mask-களைக் காட்டுவதற்கு இந்த விலக்கே மிக முக்கியமான காரணமாகும்.

ஒரு private group-ல் ஒரே ஒரு உறுப்பினர் மட்டுமே இருப்பார் என்பதால், group-writable என்பது owner-writable என்பதற்குச் சமம் என்பதே இந்த விதியின் பின்னணியில் உள்ள தர்க்கம். அந்த group-ல் மற்றொரு உறுப்பினர் சேர்க்கப்படும் வரை இது சரியாக இருக்கும். அந்த நொடியிலிருந்து, அந்த account இதுவரை உருவாக்கிய அனைத்து கோப்புகளும் புதிய உறுப்பினரால் மாற்றியமைக்கப்படக்கூடியதாகிவிடும்; இதற்காக எந்தக் கட்டளையும் இயக்கப்பட வேண்டியதில்லை. ஒவ்வொரு service-க்கும் அதற்கென பிரத்யேகமான least-privilege user account வழங்குங்கள்; அப்போதுதான் அந்த group வேண்டுமென்றே ஒரு உறுப்பினரை மட்டும் கொண்டதாக இருக்கும்.

Login shell, non-login shell மற்றும் non-interactive shell

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

ஒரு session உருவாக்கப்படும்போது PAM இயங்குகிறது: login console-ல், sshd, su, sudo -i. ஒரு shell மற்றொரு shell-ஐத் தொடங்கும்போது PAM இயங்குவதில்லை. bash -l ஒரு login shell என்பதால், அது /etc/profile மற்றும் ~/.profile ஆகிய கோப்புகளை வாசிக்கும். ஆனால், session உருவாக்கப்படாததால் அது pam_umask-ஐ ஒருபோதும் அழைப்பதில்லை. bash -c எந்தக் கோப்பையும் வாசிப்பதில்லை; அது தன்னைத் தொடங்கிய process-ன் mask-ஐயே பெற்றுக்கொள்கிறது. ஒரு cron job, git hook மற்றும் service manager-ஆல் தொடங்கப்பட்ட நிரல் ஆகிய அனைத்தும் இந்த கடைசி வகையைச் சேர்ந்தவை. எனவே, அவற்றின் parent process என்ன mask-ஐக் கொண்டிருந்ததோ, அதுவே அவற்றிற்கும் அமையும்.

இதனால்தான், "/etc/profile-ல் நான் அமைத்த பிறகும் service தவறான mode-ல் எழுதுகிறது" என்ற புகார் அடிக்கடி வருகிறது. அந்த service ஒருபோதும் அக்கோப்பை வாசிப்பதில்லை.

அமைப்புகளை நிரந்தரமாக்குவது எப்படி

ஒவ்வொரு தொடக்கப் பாதையும் வெவ்வேறு கோப்புகளை வாசிப்பதால், பணிச்சுமை (workload) தொடங்கும் இடத்திலேயே mask-ஐ அமைக்கவும்.

1. உள்நுழையும் கணக்குகளுக்கு: UMASK-ஐ /etc/login.defs-ல் அமைக்கவும், இது இயந்திரத்தில் உள்ள ஒவ்வொரு அமர்விற்கும் pam_umask மூலம் பயன்படுத்தப்படும். இது இயந்திரம் முழுமைக்குமானது, எனவே அனைத்து கணக்குகளையும் ஒரே நேரத்தில் மாற்றும்.
2. ஒரு குறிப்பிட்ட கணக்கிற்கு: pam_umask.so வரியில் உள்ள umask= ஆர்குமென்ட் இயந்திரம் முழுமைக்குமானது, எனவே ஒரு பயனருக்கான மதிப்பு அந்த பயனரின் GECOS புலத்தில் இருக்க வேண்டும், அல்லது login shells-க்கு ~/.profile-லும், interactive shells-க்கு ~/.bashrc-லும் இருக்க வேண்டும்.
3. systemd-ன் கீழ் இயங்கும் daemon-க்கு: unit-ன் [Service] பகுதியில் UMask=-ஐ அமைக்கவும். ஒரு unit service manager-ஆல் தொடங்கப்படுவதால், /etc/profile ஒருபோதும் வாசிக்கப்படாது மற்றும் pam_umask இயங்காது. daemon-ஐச் சென்றடையும் ஒரே கோப்பு unit file மட்டுமே.
4. cron அல்லது hook மூலம் தொடங்கப்படும் script-க்கு: script எதையும் உருவாக்குவதற்கு முன்பு, அதன் முதல் வரியில் ஒரு தெளிவான umask-ஐச் சேர்க்கவும்.

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

பின்னர், அதே பாதையில் இருந்து புதிய தொடக்கத்தின் மூலம் சரிபார்க்கவும்; கோப்பைத் திருத்திய shell-லிருந்து சரிபார்க்க வேண்டாம். உங்கள் தற்போதைய shell ஏற்கனவே அதன் mask-ஐக் கொண்டுள்ளது, மேலும் ஒரு config கோப்பைத் திருத்துவது இயங்கிக்கொண்டிருக்கும் process-ஐப் பாதிக்காது.

bash -lc 'umask'
sudo -i umask

chmod கட்டளையைத் தொடர்ந்து பயன்படுத்துவது ஏன் சரியான தீர்வல்ல

chmod ஏற்கனவே உள்ள கோப்புகளை மட்டுமே சரிசெய்கிறது. ஆனால், இன்னும் உருவாக்கப்படாத கோப்புகளின் பயன்முறை (mode) எதைக் கொண்டு தீர்மானிக்கப்படுகிறது என்பதை umask தீர்மானிக்கிறது. ஒரு கோப்பகத்தில் chmod -R கட்டளையை இயக்கினாலும், அந்தச் சேவை உருவாக்கும் அடுத்த கோப்பு மீண்டும் பழைய பயன்முறையிலேயே அமையும். ஏனெனில், அந்தப் பயன்முறை கோப்பை உருவாக்கும் செயல்முறையிலிருந்து (creating process) வருகிறது, கோப்பகத்தின் அமைப்பில் எந்த மாற்றமும் செய்யப்படுவதில்லை.

மேலும், இதில் ஒரு கால இடைவெளி (window) உள்ளது. ஒரு கோப்பு உருவாக்கப்பட்ட தருணத்திற்கும், chmod கட்டளை இயக்கப்படும் தருணத்திற்கும் இடையில், அந்தக் கோப்பு அதிக அனுமதிகளுடன் வட்டில் (disk) இருக்கும். கோப்பகத்தை வாசிக்கக்கூடிய எந்தவொரு செயல்முறையும் அந்தக் கோப்பைத் திறக்க முடியும். ஒரு தனிப்பட்ட விசை (private key) அல்லது காப்புப்பிரதி கோப்பிற்கு (backup archive), இந்த இடைவெளிதான் நீங்கள் தவிர்க்க முயன்ற ஆபத்தாகும்.

அதற்குப் பதிலாக, கோப்பு உருவாக்கப்படும்போதே அதன் பயன்முறையை அமைக்கவும். install -m u=rw,go= newfile /etc/app/newfile கட்டளை இலக்கு கோப்பை ஒரு குறிப்பிட்ட பயன்முறையுடன் எழுதுகிறது, mkdir -m கட்டளை கோப்பகத்திற்கும் இதையே செய்கிறது. இவை இரண்டும் நீங்கள் குறிப்பிடும் பயன்முறையை எடுத்துக்கொண்டு, umask-ஐப் புறக்கணிக்கின்றன. ssh-keygen தான் எழுதும் தனிப்பட்ட விசைக்கு பயன்முறையை அமைக்கிறது; இதனால்தான் மற்ற கோப்புகள் தவறாக இருந்தாலும், இந்த ஒரு கோப்பு மட்டும் பெரும்பாலும் சரியாக இருக்கிறது.

இதில் வழக்கமாகப் பாதிக்கப்படுவது SSH ஆகும். ஒரு சாதாரண mkdir மூலம் உருவாக்கப்பட்ட ~/.ssh, அல்லது cat >> மூலம் சேர்க்கப்பட்ட authorized_keys, உங்கள் shell-ன் umask-ஐ எடுத்துக்கொள்கிறது. StrictModes செயல்பாட்டில் இருக்கும்போது, குழுவினர் எழுதக்கூடிய (group-writable) கோப்பகத்தில் உள்ள விசை கோப்பை வாசிக்க sshd மறுத்துவிடும். கிளையண்டிற்கு Permission denied (publickey) என்று காட்டப்படும், அதே சமயம் சர்வரின் /var/log/auth.log உண்மையான காரணத்தைப் பதிவு செய்யும்:

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

இந்தச் சரிபார்ப்பு வேண்டுமென்றே செய்யப்படுகிறது, மேலும் VPS-ல் SSH-ஐப் பாதுகாத்தல் என்பது இது சரியாகச் செயல்படுவதைப் பொறுத்தே அமையும். புதிய சர்வரில் கணக்குகளை உருவாக்கும் முன்பே, புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்பதோடு சேர்த்து, umask-ஐ அளவிடவும். அப்போதுதான் அந்த கணக்குகள் உருவாக்கும் ஒவ்வொரு கோப்பின் பயன்முறையும் முன்கூட்டியே தீர்மானிக்கப்படும்.

நகல்கள் மற்றும் காப்பகங்கள் mask-ஐப் புறக்கணிக்கின்றன

cp -p மற்றும் rsync -a ஆகியவை source file-ல் பதிவுசெய்யப்பட்ட mode-ஐ மீட்டெடுக்கின்றன, எனவே இந்தச் செயல்பாட்டில் mask-க்கு எந்தப் பங்கும் இல்லை. tar root பயனராகவோ அல்லது -p-ஐப் பயன்படுத்தும் சாதாரண பயனராகவோ கோப்புகளைப் பிரித்தெடுக்கும்போது இதையே செய்கிறது. காப்புப்பிரதியிலிருந்து (backup) மீட்டெடுக்கப்பட்ட ஒரு கோப்பு, காப்புப்பிரதி எடுக்கப்பட்டபோது அதற்கு இருந்த mode-ஐயே தக்கவைத்துக்கொள்ளும். சரியான mask புறக்கணிக்கப்படுகிறது என்று முடிவெடுக்கும் முன் இதைச் சரிபார்க்கவும்: மீட்டெடுக்கப்பட்ட தரவுகளுக்கு mask ஒருபோதும் பயன்படுத்தப்படுவதில்லை.

FAQ

எனது cron job ஏன் எனது ssh session-ல் இருந்து மாறுபட்ட mode-ல் கோப்புகளை உருவாக்குகிறது?

Cron job என்பது ஒரு login session அல்ல, எனவே அதற்காக pam_umask ஒருபோதும் இயங்காது. மேலும் அது /etc/profile அல்லது ~/.profile ஆகியவற்றை வாசிப்பதில்லை. அது தன்னைத் தொடங்கிய process-ன் mask-ஐயே பெறுகிறது. ஒரு கோப்பை உருவாக்கும் முன், script-ன் முதல் வரியில் ஒரு தெளிவான umask-ஐச் சேர்க்கவும். உங்கள் shell-ல் என்ன உள்ளது என்பதை விட, அந்த job-ல் உண்மையில் என்ன mask உள்ளது என்பதைப் பார்க்க, job-க்கு உள்ளிருந்தே அதை ஒருமுறை print செய்யவும்.

/etc/login.defs ஒரு விஷயத்தைச் சொல்ல, எனது shell வேறொன்றைக் காட்டுவது ஏன்?

/etc/login.defs-ல் உள்ள UMASK என்பது pam_umask-க்கான கடைசி மாற்று வழி மட்டுமே. இந்த module, பயனரின் GECOS field-ல் உள்ள umask= entry-க்கும், பின்னர் /etc/pam.d/-ல் உள்ள pam_umask.so வரியில் உள்ள umask= argument-க்கும் முன்னுரிமை அளிக்கிறது. USERGROUPS_ENAB மூலம் செயல்படுத்தப்படும் usergroups செயல்பாடு, primary group பெயரும் பயனர் பெயரும் ஒன்றாக இருக்கும் எந்தவொரு non-root account-க்கும் group digit-ஐ மாற்றியமைக்கும். உங்கள் account-க்கு எது பொருந்தும் என்பதைப் பார்க்க grep -rn pam_umask /etc/pam.d/ மற்றும் id -un; id -gn ஆகியவற்றை இயக்கவும்.

ஒரு umask மூலம் கோப்பை executable ஆக்க முடியுமா?

முடியாது. ஒரு நிரல் கோப்பை உருவாக்கும்போது கேட்கும் bits-லிருந்து சிலவற்றை மட்டுமே mask-ஆல் நீக்க முடியும். touch ஒருபோதும் execute bit-ஐக் கோருவதில்லை, எனவே எந்த mask-உம் ஒரு executable கோப்பை உருவாக்காது. இதை ஒரு தற்காலிக directory-ல் ( umask a=rwx; touch f; stat -c '%a %A' f ) மூலம் உறுதிப்படுத்தவும். Execute bit-ஐப் பெற உங்களுக்கு chmod தேவை, அல்லது உருவாக்கும்போதே அதைக் கோரும் install -m போன்ற ஒரு நிரல் தேவை.

systemd service-க்கான umask-ஐ நான் எங்கே அமைக்க வேண்டும்?

Unit கோப்பில், [Service] பிரிவில் UMask= மூலம் அமைக்க வேண்டும். ஒரு service, login மூலம் தொடங்கப்படாமல் service manager மூலம் தொடங்கப்படுவதால், shell startup கோப்புகள் வாசிக்கப்படுவதில்லை மற்றும் pam_umask இயங்குவதில்லை. systemctl daemon-reload மற்றும் unit-ஐ restart செய்த பிறகு, வெளியே இருந்து உறுதிப்படுத்தவும்: service-ஐ ஒரு கோப்பை உருவாக்கச் சொல்லி, அதன் முடிவை stat -c '%a %n' மூலம் சரிபார்க்கவும்.

group-writable default mask பாதுகாப்பானதா?

அந்த group-ல் ஒரே ஒரு உறுப்பினர் மட்டுமே இருக்கும் வரை இது பாதுகாப்பானது; இதுவே user private group திட்டத்தின் அடிப்படை அனுமானம். அந்த group-ல் இரண்டாவது account-ஐச் சேர்த்தால், முதல் account உருவாக்கிய அனைத்து கோப்புகளும் புதிய உறுப்பினரால் உடனடியாக மாற்றக்கூடியதாகிவிடும்; அந்தக் கோப்புகளில் எந்தக் கட்டளையும் இயக்கத் தேவையில்லை. id -un மற்றும் id -gn ஆகியவற்றை இயக்கவும்: ஒரே பெயர் கிடைத்தால் நீங்கள் private group-ல் இருக்கிறீர்கள் என்று அர்த்தம். நீங்கள் பல account-களுக்கு இடையே ஒரு group-ஐப் பகிர்ந்தால், group write bit-ஐ நீக்கும் mask-ஐ அமைக்கவும், பின்னர் ஒரு கோப்பை உருவாக்கி stat -c '%a %n' மூலம் மாற்றம் நிகழ்ந்ததை உறுதிப்படுத்தவும்.