Linux-এ umask কী এবং কীভাবে কাজ করে

Linux-এ umask যা করে

umask হলো Linux-এর প্রতিটি প্রসেসের সাথে থাকা একটি সংখ্যা, যা ওই প্রসেস দ্বারা তৈরি প্রতিটি ফাইল এবং ডিরেক্টরির মোড (mode) নির্ধারণ করে। কোনো প্রোগ্রাম ফাইল তৈরির সময় কার্নেলের কাছে নির্দিষ্ট কিছু অনুমতির (permissions) আবেদন করে। কার্নেল মাস্কের মধ্যে থাকা প্রতিটি বিট মুছে ফেলে এবং বাকি অংশটুকু প্রয়োগ করে। umask কখনোই নতুন কোনো অ্যাক্সেস প্রদান করে না। এটি কেবল তৈরি করা প্রোগ্রামের চাওয়া অনুমতি থেকে কিছু বিট কমিয়ে দেয়।

এই মানটি আপনার ডিস্ট্রিবিউশনের কোনো বৈশিষ্ট্য নয়। এটি নির্ভর করে আপনি কোন অ্যাকাউন্টে আছেন এবং শেলটি কীভাবে চালু হয়েছে তার ওপর। একটি স্টক ইমেজে একই সময়ে, একই মেশিনে এই দুটি উত্তর ভিন্ন হতে পারে। তাই প্রথম পদক্ষেপটি কোনো ম্যানুয়াল খোঁজা নয়। বরং আপনার সামনে থাকা মেশিনে এর মান পরিমাপ করা।

আপনার বর্তমান শেল-এ umask প্রিন্ট করুন

umask
umask -S

প্রথম ফরম্যাটটি অক্টাল (octal) আকারে মাস্কটি প্রিন্ট করে। দ্বিতীয়টি একই মাস্ককে পারমিশন হিসেবে দেখায়, যা chmod গ্রহণ করে এমন সিম্বলিক ফরম্যাটে থাকে। উভয় লাইন স্ক্রিনে রাখুন। নিচে যা কিছু আছে তা আপনার শেল-এর প্রিন্ট করা আউটপুটের সাথে তুলনা করার জন্য।

umask একটি শেল বিল্টইন (builtin), এটি ডিস্কে থাকা কোনো আলাদা প্রোগ্রাম নয়। type umask ব্যবহার করে তা নিশ্চিত করুন। এটি গুরুত্বপূর্ণ, কারণ একটি বিল্টইন সরাসরি শেল প্রসেসকেই পরিবর্তন করে। একটি আলাদা প্রোগ্রাম কেবল তার নিজস্ব প্রসেস পরিবর্তন করতে পারে, এবং প্রসেসটি শেষ হয়ে গেলে সেই পরিবর্তনও হারিয়ে যায়।

একটি ফাইল ও একটি ডিরেক্টরি তৈরি করুন, তারপর মোডগুলো পুনরায় পড়ুন

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 ব্যবহার করে। উভয় লাইনকে কিছুক্ষণ আগে প্রিন্ট করা মাস্কের সাথে তুলনা করুন। মাস্কের প্রতিটি সেট করা বিট মোড থেকে অনুপস্থিত থাকে, কারণ মাস্কের একমাত্র কাজ হলো সেই বিটগুলোকে মুছে ফেলা। যদি %A কলামটি বুঝতে সমস্যা হয়, তবে drwxr-xr-x পারমিশন স্ট্রিং বিষয়টি আগে ভালোভাবে বুঝে নেওয়া প্রয়োজন।

ফাইল এবং ডিরেক্টরি একে অপরের থেকে আলাদা, এবং এই পার্থক্যের কারণ মাস্ক নয়। touch কার্নেলের কাছে মালিক, গ্রুপ এবং অন্যদের জন্য রিড ও রাইট পারমিশন চায়। mkdir তিনটির জন্যই রিড, রাইট এবং এক্সিকিউট পারমিশন চায়। একই মাস্ক দুটি ভিন্ন অনুরোধ থেকে বিয়োগ করা হয়। তাই touch দ্বারা তৈরি একটি ফাইল কখনোই এক্সিকিউটেবল হয় না, মাস্কে যাই থাকুক না কেন: এক্সিকিউট বিট কখনোই অনুরোধ করা হয়নি, এবং একটি মাস্ক কোনো বিট পুনরায় যোগ করতে পারে না।

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

প্যারেন্থেসিসগুলো কমান্ডগুলোকে একটি সাবশেল-এ চালায়, তাই পরিবর্তনটি সাবশেল শেষ হওয়ার সাথে সাথেই হারিয়ে যায়। মাস্কটি এখন কোনো কিছু মুছে ফেলার অনুরোধ করছে না, এবং stat ফাইলটিতে কোনো এক্সিকিউট বিট নেই বলে রিপোর্ট করছে। পরবর্তীতে আবার umask চালান এবং আপনার আসল মান ফিরে আসবে, যা প্রমাণ করে যে এই সেটিংটি একটি প্রসেসের ভেতরে থাকে এবং চাইল্ড প্রসেসে ইনহেরিট হয়, ডিস্কের কোথাও সংরক্ষিত থাকে না।

ডিরেক্টরির ক্ষেত্রে এক্সিকিউট বিট মুছে ফেলার প্রভাব স্পষ্ট বোঝা যায়।

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

একজন সাধারণ ব্যবহারকারী হিসেবে cd কমান্ডটি bash: cd: noexec.dir: Permission denied এর কারণে ব্যর্থ হয়, কারণ মাস্কটি mkdir এর অনুরোধ করা এক্সিকিউট বিটটি মুছে ফেলেছে, এবং এক্সিকিউট বিট ছাড়া কোনো ডিরেক্টরিতে প্রবেশ করা সম্ভব নয়। রুট ইউজার এই চেকটি এড়িয়ে যায়, তাই এটি শুধুমাত্র একটি সাধারণ অ্যাকাউন্টের ক্ষেত্রেই দেখা যায়।

কেন root এবং আপনার নিজস্ব user ভিন্ন umask দেখে

অন্য একটি account-এর মাধ্যমে একই পরিমাপ চালান, যা ভিন্নভাবে শুরু হয়েছে, এবং দুটি output পাশাপাশি রেখে দেখুন।

umask
sudo -i umask

sudo -i কমান্ডটি root-এর login shell শুরু করে এবং তার ভেতরে builtin কমান্ডটি চালায়, তাই এটি ভিন্ন একটি startup path দিয়ে আসা ভিন্ন একটি account। সাধারণ Ubuntu এবং Debian server image-এ এই দুটি লাইন ভিন্ন মান দেখাতে পারে। উভয় লাইনই সঠিক। প্রতিটি লাইন দেখায় যে তার নিজস্ব startup path কী তৈরি করেছে, এবং এই পোস্টের বাকি অংশটি হলো সিস্টেমের কোন অংশ এটি তৈরি করেছে তা নিয়ে।

আপনার ইমেজের কোন ফাইলটি মান নির্ধারণ করেছে

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 কোনো ফলাফল না দেখায়, তবে ^ অ্যাঙ্কর ছাড়াই এটি আবার চালান: লাইনটি কমেন্ট করা থাকতে পারে এবং একটি কমেন্ট করা লাইন কনফিগারেশনের পরিবর্তে ডকুমেন্টেশন হিসেবে গণ্য হয়। তৃতীয় grep-টি সাধারণত সবাইকে অবাক করে। Debian এবং Ubuntu-তে সরবরাহকৃত /etc/profile মূলত নিজেই কোনো মাস্ক সেট করার পরিবর্তে PAM-এর দিকে নির্দেশ করে, তাই আপনি যে ফাইলটিকে দায়ী মনে করেছিলেন সেটি প্রায়শই তা নয়। grep কোনো কিছু খুঁজে না পেলে নন-জিরো (non-zero) এক্সিট কোড প্রদান করে, আর এই কারণেই লাইনটি || echo দিয়ে শেষ হয়েছে: এমন কোনো ইমেজে যেখানে কোনো স্টার্টআপ ফাইলে মাস্কের উল্লেখ নেই, সেখানে আপনি নীরবতার পরিবর্তে বার্তাটি পাবেন এবং এই বার্তাই হলো আপনার অনুসন্ধান।

/etc/login.defs একটি মান প্রচার করে এবং PAM অন্য একটি মান প্রয়োগ করে

/etc/login.defs ফাইলের UMASK লাইনটি এমন একটি মান যা বেশিরভাগ গাইড উল্লেখ করে। কার্নেল বা শেল কেউই এই ফাইলটি পড়ে না। এটি pam_umask দ্বারা পড়া হয়, যা একটি PAM (pluggable authentication modules) মডিউল এবং সেশন তৈরি হওয়ার সময় এটি কার্যকর হয়। pam_umask প্রথম যে মানটি পায় সেটি গ্রহণ করে: ব্যবহারকারীর GECOS ফিল্ডে থাকা একটি umask= এন্ট্রি, তারপর pam_umask.so লাইনে সরাসরি লেখা একটি umask= আর্গুমেন্ট, এবং সবশেষে /etc/login.defs থেকে পাওয়া UMASK। ডিস্ট্রিবিউশনগুলো এই মডিউলটিকে প্যাচ করে, তাই আপনার নিজের ইমেজে man pam_umask কমান্ডটি চালান এবং সেখানে প্রদর্শিত ক্রমটি পড়ুন।

এভাবেই /etc/login.defs একটি মান প্রচার করতে পারে অথচ আপনার সেশন অন্য একটি মান নিয়ে শেষ হয়, এবং কোনো পক্ষেই কোনো সতর্কবার্তা দেওয়া হয় না। grep কমান্ডগুলো আপনাকে জানাবে আপনি কোন পরিস্থিতিতে আছেন। যদি pam_umask.so লাইনে নিজস্ব umask= আর্গুমেন্ট থাকে, তবে login.defs-এর লাইনটি কার্যকর হয় না।

USERGROUPS_ENAB এবং root-এর ক্ষেত্রে ব্যতিক্রম

id -un
id -gn

যদি এই দুটি কমান্ড একই নাম প্রদর্শন করে, তবে আপনার একটি user private group রয়েছে: অ্যাকাউন্টটি তৈরি করার সময় সেটির নামে একটি নিজস্ব গ্রুপ তৈরি করা হয়েছিল। pam_umask-এর একটি usergroups আচরণ রয়েছে, যা /etc/login.defs ফাইলের USERGROUPS_ENAB দ্বারা নিয়ন্ত্রিত হয়। যখন এটি চালু থাকে এবং অ্যাকাউন্টটি root নয়, আর প্রাথমিক গ্রুপের নাম ব্যবহারকারীর নামের সাথে মিলে যায়, তখন এই মডিউলটি mask-এর owner digit-কে group digit-এ কপি করে। এর ফলে সেশনটি এমন একটি mask নিয়ে শেষ হয় যা ওই অ্যাকাউন্টের তৈরি করা সবকিছুর group bits-কে উন্মুক্ত রাখে। মডিউলটি নিজেই root-কে এই প্রক্রিয়ার বাইরে রাখে এবং এই বর্জনই হলো একটি সার্ভারে দুটি ভিন্ন shell-এ ভিন্ন mask দেখানোর সবচেয়ে সাধারণ কারণ।

এই নিয়মের পেছনের যুক্তি হলো, একটি private group-এ কেবল একজনই সদস্য থাকে, তাই group-writable হওয়ার অর্থ হলো owner-writable হওয়া এবং এর বেশি কিছু নয়। এটি ততক্ষণ পর্যন্ত কার্যকর থাকে যতক্ষণ না কেউ ওই গ্রুপে দ্বিতীয় কোনো সদস্য যোগ করে। সেই মুহূর্ত থেকে ওই অ্যাকাউন্টের তৈরি করা প্রতিটি ফাইল নতুন সদস্যের জন্য writable হয়ে যায়, অথচ ফাইলগুলোতে এমন কোনো কমান্ড চালানো হয়নি যা সেগুলোকে writable করে তোলে। প্রতিটি সার্ভিসকে তার নিজস্ব least-privilege user account দিন, তাহলেই সেই গ্রুপটি উদ্দেশ্যমূলকভাবে কেবল একজনের গ্রুপ হিসেবেই থাকবে।

Login shell, non-login shell এবং non-interactive shell

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

যখন একটি session তৈরি হয় তখন PAM রান করে: console-এ login, sshd, su, sudo -i। একটি shell যখন অন্য একটি shell শুরু করে তখন এটি রান করে না। bash -l একটি login shell, তাই এটি /etc/profile এবং ~/.profile পড়ে, কিন্তু এটি কখনোই pam_umask কল করে না, কারণ কোনো session তৈরি হয়নি। bash -c এই ফাইলগুলোর কোনোটিই পড়ে না এবং যে process-টি একে শুরু করেছে তার mask উত্তরাধিকারসূত্রে গ্রহণ করে। একটি cron job, একটি git hook এবং একটি service manager দ্বারা শুরু করা প্রোগ্রাম—সবই এই শেষোক্ত পরিস্থিতির অন্তর্ভুক্ত, তাই তাদের mask তাদের parent process-এর mask-এর সমান হয়।

এই কারণেই "/etc/profile-এ সেট করার পরেও service ভুল mode-এ ফাইল লিখছে"—এই ধরনের অভিযোগ খুব সাধারণ। কারণ service-টি কখনোই সেই ফাইলটি পড়েনি।

এটি কোথায় সেট করবেন যাতে তা স্থায়ী হয়

যেখানে ওয়ার্কলোডটি আসলে শুরু হয়, সেখানেই মাস্ক সেট করুন, কারণ প্রতিটি স্টার্ট পাথ ভিন্ন ভিন্ন ফাইল পড়ে।

1. যেসব অ্যাকাউন্ট লগ-ইন করে তাদের জন্য: UMASK ফাইলটি /etc/login.defs-এ থাকে, যা মেশিনের প্রতিটি সেশনের জন্য pam_umask দ্বারা প্রয়োগ করা হয়। এটি পুরো মেশিনের জন্য প্রযোজ্য, তাই এটি একসাথে সব অ্যাকাউন্টের সেটিংস পরিবর্তন করে।
2. একটি নির্দিষ্ট অ্যাকাউন্টের জন্য: pam_umask.so লাইনের umask= আর্গুমেন্টটিও পুরো মেশিনের জন্য প্রযোজ্য। তাই প্রতি-ব্যবহারকারী (per-user) মান সেট করতে হলে তা ব্যবহারকারীর GECOS ফিল্ডে, অথবা লগ-ইন শেলের জন্য ~/.profile-এ এবং ইন্টারঅ্যাক্টিভ শেলের জন্য ~/.bashrc-এ রাখতে হবে।
3. systemd-এর অধীনে চলা ডেমনের জন্য: ইউনিটের [Service] সেকশনে UMask= ব্যবহার করুন। একটি ইউনিট সার্ভিস ম্যানেজার দ্বারা শুরু হয়, তাই /etc/profile কখনোই পড়া হয় না এবং pam_umask কখনোই রান করে না। ডেমনের ক্ষেত্রে শুধুমাত্র ইউনিট ফাইলটিই কার্যকর হয়।
4. cron বা কোনো হুক দ্বারা শুরু হওয়া স্ক্রিপ্টের জন্য: স্ক্রিপ্টটি কিছু তৈরি করার আগেই প্রথম লাইনে একটি স্পষ্ট umask কমান্ড ব্যবহার করুন।

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

এরপর সেই একই পাথ থেকে নতুন করে শুরু করে যাচাই করুন, যে শেলের মাধ্যমে ফাইলটি এডিট করেছেন সেখান থেকে নয়। আপনার বর্তমান শেলটি ইতিমধ্যে তার নিজস্ব মাস্ক ধরে রেখেছে এবং কনফিগারেশন ফাইল এডিট করলে তা চলমান প্রসেসের ওপর কোনো প্রভাব ফেলে না।

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 তার লেখা প্রাইভেট কি-এর মোড নিজেই সেট করে, আর এই কারণেই একটি মেশিনে অন্য সব ফাইল ভুল মোডে থাকলেও এই একটি ফাইল প্রায়ই সঠিক মোডে থাকে।

এক্ষেত্রে সাধারণত SSH ক্ষতিগ্রস্ত হয়। সাধারণ mkdir দিয়ে তৈরি করা ~/.ssh, অথবা cat >> দিয়ে যুক্ত করা authorized_keys, আপনার শেলের umask গ্রহণ করে। StrictModes চালু থাকলে, sshd গ্রুপ-রাইটেবল ডিরেক্টরি থেকে কোনো কি ফাইল পড়তে অস্বীকার করে। ক্লায়েন্টকে Permission denied (publickey) বার্তা দেখানো হয়, অথচ সার্ভারের /var/log/auth.log-এ আসল কারণটি রেকর্ড করা থাকে:

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

এই চেকটি ইচ্ছাকৃতভাবেই দেওয়া হয়েছে এবং VPS-এ SSH হার্ডেনিং এর ওপরই নির্ভর করে। নতুন সার্ভারে অ্যাকাউন্ট তৈরি করার আগেই umask পরিমাপ করুন, যা নতুন VPS-এ প্রথম দশ মিনিট-এর কাজের পাশাপাশি করতে হয়। এতে ওই অ্যাকাউন্টগুলো যে ফাইলই তৈরি করুক না কেন, সেগুলোর মোড আগে থেকেই নির্ধারিত হয়ে যাবে।

কপি এবং আর্কাইভ করার সময় মাস্ক উপেক্ষা করা হয়

cp -p এবং rsync -a সোর্স ফাইলে রেকর্ড করা মোড পুনরুদ্ধার করে, তাই ফলাফলের ক্ষেত্রে মাস্কের কোনো ভূমিকা থাকে না। tar যখন root হিসেবে অথবা -p ব্যবহারকারী সাধারণ ব্যবহারকারী হিসেবে ফাইল এক্সট্র্যাক্ট করে, তখনও একই কাজ করে। ব্যাকআপ থেকে পুনরুদ্ধার করা একটি ফাইল ব্যাকআপ তৈরির সময় যে মোডে ছিল, সেই মোডেই থাকে। সঠিক মাস্ক উপেক্ষা করা হচ্ছে কি না তা নিশ্চিত হওয়ার আগে এটি পরীক্ষা করে দেখুন: পুনরুদ্ধার করা ডেটার ক্ষেত্রে মাস্ক কখনোই যাচাই করা হয়নি।

FAQ

আমার cron job কেন আমার ssh session-এর চেয়ে ভিন্ন mode-এ ফাইল তৈরি করে?

cron job কোনো login session নয়, তাই এর জন্য pam_umask কখনোই চলে না এবং এটি /etc/profile বা ~/.profile কোনোটিই পড়ে না। এটি যে process-টি একে শুরু করেছে, তার mask উত্তরাধিকারসূত্রে পায়। স্ক্রিপ্টের প্রথম লাইনে কোনো কিছু তৈরি করার আগেই একটি স্পষ্ট umask যোগ করুন। এছাড়া job-এর ভেতর থেকে একবার mask-টি print করুন, যাতে আপনার নিজের shell-এর পরিবর্তে job-টি আসলে কী mask ব্যবহার করছে তা দেখতে পারেন।

/etc/login.defs-এ একরকম লেখা থাকলেও আমার shell কেন অন্যরকম দেখাচ্ছে?

/etc/login.defs-এর UMASK শুধুমাত্র pam_umask-এর জন্য সর্বশেষ fallback হিসেবে কাজ করে। এই module-টি প্রথমে ব্যবহারকারীর GECOS field-এ থাকা umask= entry-কে প্রাধান্য দেয়, এরপর /etc/pam.d/-এর pam_umask.so লাইনে থাকা umask= argument-কে দেখে। USERGROUPS_ENAB দ্বারা সক্রিয় করা usergroups আচরণটি এমন যেকোনো non-root account-এর জন্য group digit-কে নতুন করে লিখে দেয়, যার primary group-এর নাম তার নিজের নামের সাথে মিলে যায়। আপনার account-এর ক্ষেত্রে কোনটি প্রযোজ্য তা দেখতে grep -rn pam_umask /etc/pam.d/ এবং id -un; id -gn চালান।

umask কি কোনো ফাইলকে executable করতে পারে?

না। একটি mask শুধুমাত্র সেই bit-গুলোই মুছে ফেলতে পারে যা তৈরি করা প্রোগ্রামটি চেয়েছিল। touch কখনোই execute bit-এর জন্য অনুরোধ করে না, তাই কোনো mask-ই executable ফাইল তৈরি করতে পারে না। একটি throwaway directory-তে ( umask a=rwx; touch f; stat -c '%a %A' f ) দিয়ে এটি নিশ্চিত করুন। execute bit পাওয়ার জন্য আপনার chmod প্রয়োজন, অথবা install -m-এর মতো এমন কোনো প্রোগ্রাম প্রয়োজন যা ফাইল তৈরির সময় এর জন্য অনুরোধ করে।

systemd service-এর জন্য আমি কোথায় umask সেট করব?

unit file-এর [Service] section-এ 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-এর তৈরি করা প্রতিটি ফাইল সাথে সাথে নতুন সদস্যের জন্য writable হয়ে যায়, এবং ফাইলগুলোর ওপর কোনো কমান্ড চালানোর প্রয়োজন হয় না। id -un এবং id -gn চালান: একই নাম print হওয়া মানে আপনি একটি private group-এ আছেন। যদি আপনি একাধিক account-এর মধ্যে একটি group শেয়ার করেন, তবে এমন একটি mask সেট করুন যা group write bit মুছে ফেলে, তারপর একটি ফাইল তৈরি করে stat -c '%a %n' পড়ুন যাতে পরিবর্তনটি কার্যকর হয়েছে কি না তা নিশ্চিত হওয়া যায়।