Linux umask: default permissions कुठून सुरू होतात

Linux वर umask काय करते

Linux मधील प्रत्येक process सोबत umask ही संख्या असते. तो process तयार करत असलेल्या प्रत्येक file आणि directory चा mode umask ठरवतो. एखादा program निर्मितीच्या वेळी kernel कडे permissions चा संच मागतो. kernel mask मध्ये नमूद केलेले प्रत्येक bit clear करतो आणि उरलेले permissions लागू करतो. umask कधीही access देत नाही. तयार करणाऱ्या program ने मागितलेल्या permissions मधून तो फक्त काही bits काढून टाकतो.

ही value तुमच्या distribution ची property नाही. तुम्ही कोणत्या account ने काम करत आहात आणि shell कसा सुरू झाला यावर ती अवलंबून असते. एकाच machine वर, एकाच वेळी, stock image मध्येही या दोन्ही परिस्थितींचे परिणाम वेगळे असू शकतात. त्यामुळे पहिली पायरी manual मध्ये lookup करणे नाही. तुमच्यासमोरील machine वर प्रत्यक्ष मोजमाप करणे ही पहिली पायरी आहे.

तुम्ही वापरत असलेल्या shell मध्ये umask प्रदर्शित करा

umask
umask -S

पहिल्या प्रकारात mask octal स्वरूपात प्रदर्शित होतो. दुसऱ्या प्रकारात तोच mask, त्याने अनुमती दिलेल्या permissions म्हणून, chmod स्वीकारत असलेल्या symbolic स्वरूपात प्रदर्शित होतो. दोन्ही ओळी स्क्रीनवर ठेवा. पुढील सर्व मजकूर तुमच्या shell ने नुकतेच प्रदर्शित केलेल्या परिणामाशी तुलना करतो.

umask हा shell builtin आहे; डिस्कवरील program नाही. type umask वापरून याची पुष्टी करा. हे महत्त्वाचे आहे, कारण builtin स्वतः shell process मध्ये बदल करतो. स्वतंत्र program स्वतःच्या process मध्येच बदल करू शकतो. त्यानंतर तो exit होईल आणि केलेला बदलही त्याच्यासोबत निघून जाईल.

फाइल आणि डिरेक्टरी तयार करा, त्यानंतर त्यांचे modes पुन्हा वाचा

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

%a mode octal स्वरूपात दाखवते आणि %A तोच mode drwxr-xr-x स्वरूपात दाखवते, जे ls -l वापरते. दोन्ही ओळी थोड्या आधी दाखवलेल्या mask शी तुलना करा. mask मध्ये set असलेला प्रत्येक bit modes मधून वगळलेला असतो, कारण ते bits clear करणे एवढेच mask चे कार्य आहे. %A column वाचणे अजून स्पष्ट नसेल, तर drwxr-xr-x permission string आधी नीट समजून घ्या.

फाइल आणि डिरेक्टरी एकमेकांपेक्षा वेगळे असतात. या फरकाचे कारण mask नाही. touch owner, group आणि other यांच्यासाठी read आणि write मागते. mkdir तिन्हींसाठी read, write आणि execute मागते. एकाच mask मधून दोन वेगवेगळ्या requests वजा केल्या जातात. त्यामुळे touch ने तयार केलेली फाइल mask मध्ये काहीही असले तरी executable कधीच होत नाही. execute bit कधी मागितलाच गेला नव्हता आणि mask तो bit पुन्हा जोडू शकत नाही.

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

कंसातील commands subshell मध्ये चालतात. त्यामुळे केलेला बदल subshell संपल्यावर नष्ट होतो. आता mask मध्ये काहीही clear करण्याची विनंती नाही. तरीही stat फाइलमध्ये execute bit नसल्याचे दाखवते. त्यानंतर पुन्हा umask चालवा. तुमची मूळ value परत दिसेल. यावरून हे setting disk वर कुठेही साठवले जात नाही, तर process मध्ये राहते आणि child processes कडे inherited होते, हे दिसते.

Clear केलेला execute bit डिरेक्टरींमध्ये स्पष्टपणे जाणवतो.

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

सामान्य user म्हणून cd अयशस्वी होते आणि bash: cd: noexec.dir: Permission denied दाखवते. कारण mask ने mkdir ने मागितलेला execute bit clear केला आहे. execute bit नसलेली डिरेक्टरी उघडता येत नाही. root ही तपासणी वगळतो. त्यामुळे हा परिणाम फक्त सामान्य account वर दिसतो.

root आणि तुमच्या स्वतःच्या user ला वेगळा umask का दिसतो

दुसऱ्या account मधून, वेगळ्या पद्धतीने सुरू करून, तेच मापन चालवा आणि दोन्ही output शेजारीशेजारी वाचा.

umask
sudo -i umask

sudo -i root चा login shell सुरू करतो आणि त्याच्या आत builtin चालवतो. त्यामुळे हा वेगळ्या startup path मधून आलेला वेगळा account आहे. Stock Ubuntu आणि Debian server images मध्ये या दोन ओळी वेगवेगळी values दाखवू शकतात. दोन्ही ओळी योग्य आहेत. प्रत्येक ओळ तिच्या startup path मधून तयार झालेली value दाखवते. या पोस्टच्या उर्वरित भागात ती value system च्या कोणत्या घटकाने तयार केली हे स्पष्ट केले आहे.

तुमच्या image मधील कोणत्या file ने ही value ठरवली

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 मधून काहीही output मिळत नसेल, तर ^ anchor काढून पुन्हा तोच command चालवा: ही line comment केलेली असू शकते. Comment केलेली line ही configuration नसून documentation असते. तिसरा grep लोकांना सहसा आश्चर्यचकित करतो. Debian आणि Ubuntu वर उपलब्ध करून दिलेले /etc/profile बहुतेक वेळा mask स्वतः सेट करण्याऐवजी PAM कडे निर्देश करते. त्यामुळे जबाबदार file म्हणून तुम्ही गृहीत धरलेली file प्रत्यक्षात जबाबदार नसू शकते. काहीही जुळले नाही तर grep non-zero status ने बाहेर पडते. म्हणून त्या line च्या शेवटी || echo आहे: ज्या image मधील कोणत्याही startup file मध्ये maskचा उल्लेख नाही, तिथे शांत राहण्याऐवजी message मिळतो. हाच message म्हणजे शोधाचा निष्कर्ष.

/etc/login.defs एक मूल्य दर्शवते आणि PAM ते लागू करते

UMASK मधील /etc/login.defs ओळ ही बहुतेक मार्गदर्शकांमध्ये दिलेली मूल्य आहे. Kernel किंवा shell यापैकी कोणतेही pam_umask फाइल वाचत नाही. Session तयार होताना चालणारे PAM (pluggable authentication modules) module ती फाइल वाचते. pam_umask ला सापडणारे पहिले मूल्य ते स्वीकारते: वापरकर्त्याच्या GECOS field मधील umask= entry, त्यानंतर pam_umask.so ओळीवरच लिहिलेला umask= argument, आणि त्यानंतर /etc/login.defs मधील UMASK. Distributions या module मध्ये बदल करतात. त्यामुळे तुमच्या image वर man pam_umask चालवा आणि त्यात छापलेला क्रम वाचा.

त्यामुळे /etc/login.defs एक मूल्य दर्शवू शकते, पण तुमच्या session मध्ये दुसरे मूल्य लागू होऊ शकते. दोन्हीपैकी कोणत्याही ठिकाणी कोणतीही warning छापली जात नाही. कोणती परिस्थिती लागू आहे हे greps दाखवतात. pam_umask.so ओळीमध्ये स्वतःचा umask= argument असल्यास login.defs मधील ओळीला प्राधान्य राहत नाही.

USERGROUPS_ENAB आणि root अपवाद

id -un
id -gn

जर या दोन्ही आदेशांच्या output मध्ये एकच नाव दिसत असेल, तर तुमच्याकडे user private group आहे. म्हणजे account तयार करताना त्याच नावाचा स्वतंत्र group तयार करण्यात आला आहे. pam_umask मध्ये usergroups वर्तन असते. हे USERGROUPS_ENAB मधील /etc/login.defs द्वारे नियंत्रित केले जाते. हे सुरू असल्यास, account root नसल्यास आणि primary group चे नाव user name शी जुळत असल्यास, module mask मधील owner digit group digit मध्ये कॉपी करते. त्यामुळे session अशा mask सह समाप्त होते, ज्यामुळे त्या account ने तयार केलेल्या प्रत्येक गोष्टीवर group bits खुले राहतात. root ला module स्वतःच वगळते. एकाच server वरील दोन shells वेगवेगळे masks दाखवण्याचे हेच सर्वात सामान्य एकमेव कारण आहे.

या नियमामागील तर्क असा आहे की private group मध्ये नेमका एकच member असतो. त्यामुळे group-writable असणे म्हणजे फक्त owner-writable असणे. मात्र group मध्ये दुसरा member जोडल्यावर हे बदलते. त्या क्षणापासून account ने यापूर्वी तयार केलेली प्रत्येक file नवीन member कडून लिहिता येते. त्या files वर हे अधिकार लागू करण्यासाठी कोणताही command चालवलेला नसतो. प्रत्येक service साठी तिचे स्वतःचे least-privilege user account द्या. त्यामुळे तो group जाणीवपूर्वक एका member चाच राहतो.

Login shell, non-login shell आणि non-interactive shell

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

सेशन तयार झाल्यावर PAM चालते: login कन्सोलवर, sshd, su, sudo -i. एक shell दुसरा shell सुरू करतो तेव्हा PAM चालत नाही. bash -l हा login shell आहे. त्यामुळे तो /etc/profile आणि ~/.profile वाचतो. मात्र तो pam_umask कधीही कॉल करत नाही, कारण नवीन सेशन तयार झालेले नसते. bash -c यापैकी कोणतीही फाइल वाचत नाही. त्याला सुरू करणाऱ्या प्रक्रियेचा mask तो वारशाने घेतो. cron job, git hook आणि service manager ने सुरू केलेला program हे सर्व या शेवटच्या प्रकारात येतात. त्यामुळे त्यांचा mask त्यांच्या parent process कडे असलेला mask असतो.

म्हणूनच “मी /etc/profile मध्ये सेट केले, तरी service चुकीचा mode लिहिते” अशी तक्रार वारंवार आढळते. service ने ती फाइल कधीही वाचलेली नसते.

कायम राहण्यासाठी ते कुठे सेट करावे

Workload जिथून प्रत्यक्ष सुरू होते, तिथे mask सेट करा. प्रत्येक start path वेगळी file वाचतो.

1. Login करणाऱ्या accounts साठी: UMASK हे /etc/login.defs मध्ये सेट करा. pam_umask ते machine वरील प्रत्येक session ला लागू करते. हे machine-wide असल्यामुळे सर्व accounts वर एकाच वेळी परिणाम होतो.
2. एका account साठी: pam_umask.so line वरील umask= argument देखील machine-wide आहे. त्यामुळे per-user value त्या user च्या GECOS field मध्ये, किंवा login shells साठी ~/.profile मध्ये आणि interactive shells साठी ~/.bashrc मध्ये ठेवावी.
3. systemd अंतर्गत daemon साठी: unit च्या [Service] section मध्ये UMask= सेट करा. Unit service manager सुरू करतो. त्यामुळे /etc/profile कधीही वाचले जात नाही आणि pam_umask चालत नाही. या पर्यायांपैकी unit file मधील सेटिंगच daemon पर्यंत पोहोचते.
4. cron किंवा hook द्वारे सुरू होणाऱ्या script साठी: पहिल्या line वर, script काहीही तयार करण्यापूर्वी, स्पष्ट umask द्या.

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

त्यानंतर त्याच path मधून fresh start करून पडताळणी करा. File संपादित केलेल्या shell मधून कधीही पडताळणी करू नका. तुमच्या current shell मध्ये mask आधीच साठवलेला असतो. Configuration file संपादित केल्याने चालू process वर पूर्वीचा परिणाम बदलत नाही.

bash -lc 'umask'
sudo -i umask

नंतर chmod करणे हा त्याच समस्येवरील उपाय नाही

chmod आधीपासून अस्तित्वात असलेल्या फाइल्स दुरुस्त करते. अद्याप अस्तित्वात नसलेल्या फाइल्सचा mode mask ठरवतो. एखाद्या directory वर chmod -R चालवल्यानंतर service ने लिहिलेली पुढील फाइल पुन्हा जुन्या mode सह तयार होते, कारण तो mode फाइल तयार करणाऱ्या process कडून आला होता आणि directory मधील कोणतीही गोष्ट तो बदलत नाही.

यामध्ये एक कालावधीही असतो. फाइल तयार झाल्यापासून chmod चालवेपर्यंत ती फाइल अधिक व्यापक mode सह disk वर राहते. directory वाचू शकणारी कोणतीही process ती उघडू शकते. private key किंवा backup archive साठी, तुम्ही दूर करू इच्छित असलेला धोका हाच कालावधी असतो.

त्याऐवजी फाइल तयार करतानाच mode सेट करा. install -m u=rw,go= newfile /etc/app/newfile destination फाइल स्पष्ट mode सह लिहिते आणि directory साठी mkdir -m हेच करते. दोन्ही commands तुम्ही दिलेला mode वापरतात आणि mask दुर्लक्षित करतात. ssh-keygen लिहित असलेल्या private key वर mode सेट करते. म्हणून इतर सर्व फाइल्स चुकीच्या mode मध्ये असलेल्या machine वरही ती एक फाइल अनेकदा योग्य mode मध्ये असते.

सामान्यतः याचा फटका SSH ला बसतो. साध्या mkdir ने तयार केलेली ~/.ssh किंवा cat >> ने जोडलेली authorized_keys तुमच्या shell चा mask स्वीकारते. StrictModes सुरू असल्यास, group-writable directory मधून sshd key file वाचण्यास नकार देते. client ला Permission denied (publickey) संदेश दिसतो, तर server मधील /var/log/auth.log खरे कारण नोंदवते:

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

ही तपासणी जाणीवपूर्वक केली जाते आणि VPS वरील SSH hardening तिच्यावर अवलंबून असते. नवीन server वर खाते तयार करण्यापूर्वी mask तपासा. हे नवीन VPS वरील पहिल्या दहा मिनिटांमध्ये करा. त्यामुळे त्या खात्यांनी लिहिलेल्या प्रत्येक फाइलचा mode आधीच निश्चित राहतो.

प्रतिलिपी आणि संग्रह mask कडे दुर्लक्ष करतात

cp -p आणि rsync -a source file वर नोंदवलेला mode पुनर्संचयित करतात. त्यामुळे अंतिम परिणामावर mask चा प्रभाव पडत नाही. tar देखील root म्हणून extraction करताना किंवा -p वापरणाऱ्या सामान्य user म्हणून extraction करताना हेच करते. Backup मधून पुनर्संचयित केलेली file backup तयार केला तेव्हा तिचा जो mode होता तोच ठेवते. योग्य mask कडे दुर्लक्ष होत आहे असा निष्कर्ष काढण्यापूर्वी हे तपासा: पुनर्संचयित केलेल्या data साठी mask कधीही लागूच झाला नव्हता.

FAQ

माझे cron job माझ्या ssh session पेक्षा वेगळ्या mode मध्ये files का तयार करते?

cron job हे login session नसते. त्यामुळे त्यासाठी pam_umask चालत नाही आणि ते /etc/profile किंवा ~/.profile पैकी काहीही वाचत नाही. ते सुरू करणाऱ्या process चा mask त्याला वारशाने मिळतो. Script च्या पहिल्या ओळीवर, कोणतीही गोष्ट तयार होण्यापूर्वी, स्पष्ट umask लिहा. तसेच job मधून एकदा mask print करा. त्यामुळे तुमच्या स्वतःच्या shell कडे असलेल्या mask ऐवजी त्या job कडे प्रत्यक्षात कोणता mask आहे ते दिसेल.

/etc/login.defs मध्ये एक मूल्य आणि माझ्या shell मध्ये दुसरे मूल्य का दिसते?

/etc/login.defs मधील UMASK हा pam_umask साठी फक्त शेवटचा fallback आहे. Module प्रथम user च्या GECOS field मधील umask= entry वापरतो. त्यानंतर /etc/pam.d/ मधील pam_umask.so line वरील umask= argument वापरतो. USERGROUPS_ENAB ने सुरू केलेले usergroups behaviour त्यानंतर non-root account साठी group digit पुन्हा ठरवते, जर त्या account चा primary group त्याच्या नावावर असेल. तुमच्या account साठी यापैकी कोणता नियम लागू होतो ते पाहण्यासाठी grep -rn pam_umask /etc/pam.d/ आणि id -un; id -gn चालवा.

umask मुळे file executable होऊ शकते का?

नाही. Creating program ने मागितलेल्या permissions मधून mask फक्त bits काढू शकतो. touch execute bit कधीही मागत नाही. त्यामुळे कोणताही mask executable file तयार करू शकत नाही. हे throwaway directory मध्ये ( umask a=rwx; touch f; stat -c '%a %A' f ) वापरून तपासा. Execute bit मिळवण्यासाठी chmod आवश्यक आहे. किंवा creation वेळी execute bit मागणाऱ्या install -m सारख्या program ची आवश्यकता आहे.

systemd service साठी umask कुठे सेट करायचा?

Unit मध्ये [Service] section मधील UMask= वापरा. Service login कडून नव्हे, तर service manager कडून सुरू केली जाते. त्यामुळे shell startup files वाचल्या जात नाहीत आणि pam_umask तिच्यासाठी चालत नाही. systemctl daemon-reload केल्यानंतर unit restart करा. मग बाहेरून पडताळणी करा: service कडून file तयार करून घ्या आणि stat -c '%a %n' वापरून त्याचा result वाचा.

group-writable default mask सुरक्षित आहे का?

Group मध्ये नेमका एक member असेपर्यंत ते सुरक्षित आहे. User private group scheme याच गृहितकावर आधारित आहे. त्या group मध्ये दुसरे account जोडल्यास, पहिल्या account ने तयार केलेली प्रत्येक file नवीन member साठी लगेच writable होते. त्या files वर कोणताही command चालवण्याची गरज नसते. id -un आणि id -gn चालवा. समान name print झाल्यास तुम्ही private group वापरत आहात. Accounts मध्ये group share करत असल्यास group write bit clear करणारा mask सेट करा. त्यानंतर file तयार करा आणि बदल लागू झाला आहे हे सिद्ध करण्यासाठी stat -c '%a %n' वाचा.