'মালিকের' অনুমতি থাকার কি কারণ আছে? গোষ্ঠী অনুমতি কি যথেষ্ট নয়?

Question

আমি মনে করি লিনাক্সে ফাইল অনুমতিগুলি কীভাবে কাজ করে তা আমি বরং বুঝতে পারি। তবে, আমি কেন বুঝতে পারছি না যে এগুলি দুটি স্তরে নয় তিনটি স্তরে বিভক্ত।

আমি নিম্নলিখিত বিষয়গুলির উত্তর চাই:

• এই ইচ্ছাকৃত নকশা বা একটি প্যাচ? তা হ'ল - মালিক / গোষ্ঠী অনুমতিগুলি কি কিছু যৌক্তিকতার সাথে একত্রে তৈরি এবং তৈরি করা হয়েছিল বা তারা কোনও প্রয়োজনের উত্তর দিতে একের পর এক এসেছিল?
• ব্যবহারকারী / গোষ্ঠী / অন্যান্য স্কিমটি কার্যকর তবে একটি গোষ্ঠী / অন্যান্য স্কিমই যথেষ্ট নয় এমন কোনও দৃশ্য আছে?

প্রথমটির উত্তরের পাঠ্যপুস্তক বা অফিশিয়াল আলোচনা বোর্ডের উদ্ধৃতি দেওয়া উচিত।

আমি বিবেচনা করা মামলাগুলি ব্যবহার করুন:

• প্রাইভেট ফাইল - ব্যবহারকারী হিসাবে একটি গ্রুপ তৈরি করে খুব সহজেই প্রাপ্তযোগ্য, এমন কিছু যা প্রায়শই অনেক সিস্টেমে হয়।
• কেবলমাত্র একটি মালিককে (যেমন সিস্টেম পরিষেবা) কোনও ফাইলে লেখার অনুমতি দেওয়া, কেবলমাত্র একটি নির্দিষ্ট গোষ্ঠীকে পড়ার অনুমতি দেওয়া এবং অন্য সমস্ত অ্যাক্সেস অস্বীকার করা - এই উদাহরণটির সাথে সমস্যাটি হ'ল একবার গোষ্ঠীর লেখার অ্যাক্সেস পাওয়ার প্রয়োজন হয়, ব্যবহারকারী / গোষ্ঠী / অন্যান্য এতে ব্যর্থ হয়। উভয়ের উত্তর হ'ল এসিএলগুলি ব্যবহার করা হয় এবং আইএমএইচও, মালিকের অনুমতিগুলির অস্তিত্ব প্রমাণ করতে পারে না।

প্রশ্নটি সুপারউজার.কম-এ বন্ধ থাকার পরে এনবি আমি এই প্রশ্নটি পরিমার্জন করেছি ।

সম্পাদনা সম্পাদনা "তবে একটি গোষ্ঠী / মালিকের স্কিম" "..." / গোষ্ঠী / অন্যান্য ... "যথেষ্ট হবে না।

Comments

আপনি কেন ভাবেন যে গোষ্ঠী অনুমতিগুলি পর্যাপ্ত হবে তা আমি সত্যিই বুঝতে পারি না। এমন একটি পরিস্থিতি কল্পনা করুন যেখানে আপনি আপনার বিকাশকারীদের নিজস্ব ব্যক্তিগত ফাইল (কনফিগারেশন ইত্যাদি) রাখতে অনুমতি দিতে চান, তবে তাদের একে অপরের মধ্যে কোড ভাগ করার অনুমতি দিতে চান। একটি devsদল থাকা এই জন্য অনুমতি দেয়।

— ক্রিস ডাউন

@ChrisDown সে বলছে আপনি ব্যবহারকারী করতে চাই fooদলের সদস্য fooএবং devs, এবং দায়িত্ব অর্পণ করা ভাগ করা ফাইলগুলি devগোষ্ঠী ও বেসরকারি ফাইল fooগ্রুপ

— মাইকেল Mrozek

আপনি যখন এটির সাথে রয়েছেন, তখন কেন সবাই 'সদস্য' গোষ্ঠীর পরিবর্তে বিশ্ব অনুমতি রয়েছে যার প্রত্যেকেই সদস্য? উত্তরটি হ'ল ব্যবহারকারী / গোষ্ঠী / অন্যান্য অনুমতি সেটআপটি এসিএলগুলির আগে আবিষ্কার করা হয়েছিল।

— র্যান্ডম 832

Answer 1

ইতিহাস

মূলত, ইউনিক্সের কেবল নিজস্ব ব্যবহারকারী এবং অন্যান্য ব্যবহারকারীর জন্যই অনুমতি ছিল: কোনও গ্রুপ ছিল না। বিশেষত ইউনিক্স সংস্করণ 1 এর ডকুমেন্টেশন দেখুন chmod(1)। সুতরাং পশ্চাদপদ সামঞ্জস্যতা, যদি অন্য কিছু না হয় তবে তার নিজস্ব ব্যবহারকারীর জন্য অনুমতি প্রয়োজন s

দলগুলি পরে এসেছিল। কোনও ফাইলের অনুমতিতে একাধিক গোষ্ঠী জড়িত এসিএলগুলি অনেক পরে এসেছিল।

উদ্দীপনা শক্তি

একটি ফাইলের জন্য তিনটি অনুমতি থাকা খুব স্বল্প ব্যয়ে (এসিএলগুলির তুলনায় অনেক কম), মাত্র দু'জনের চেয়ে সূক্ষ্ম ধরণের অনুমতি দেয় allows উদাহরণস্বরূপ, একটি ফাইলের মোড থাকতে পারে rw-r-----: কেবলমাত্র তার নিজস্ব ব্যবহারকারীর দ্বারা লিখিত, একটি দল দ্বারা পাঠযোগ্য।

আর একটি ব্যবহারের ক্ষেত্রে সেটুকুইড এক্সিকিউটেবল যা কেবলমাত্র একটি গোষ্ঠী দ্বারা নির্বাহযোগ্য। উদাহরণস্বরূপ, মোডের rwsr-x---মালিকানাধীন একটি প্রোগ্রাম root:adminকেবলমাত্র adminগ্রুপের ব্যবহারকারীদেরই সেই প্রোগ্রামটিকে মূল হিসাবে চালাতে দেয়।

"এই স্কিমটি প্রকাশ করতে পারে না এমন অনুমতি রয়েছে" এর বিরুদ্ধে ভয়াবহ যুক্তি। প্রযোজ্য মানদণ্ডটি হ'ল, যথেষ্ট পরিমাণে সাধারণ মতামতযোগ্য মামলাগুলি যা ব্যয়টিকে ন্যায়সঙ্গত করে? এই উদাহরণস্বরূপ, ব্যয়টি সর্বনিম্ন, বিশেষত ব্যবহারকারী / গোষ্ঠী / অন্যান্য ট্রিপ্টিচের অন্যান্য কারণগুলির জন্য।

সরলতা

ব্যবহারকারী প্রতি এক গ্রুপ থাকার ওভারহেড একটি ছোট কিন্তু তুচ্ছ নয়। এটি ভাল যে একটি ব্যক্তিগত ফাইলের অত্যন্ত সাধারণ ক্ষেত্রে এটি নির্ভর করে না। একটি অ্যাপ্লিকেশন যা একটি প্রাইভেট ফাইল তৈরি করে (উদাহরণস্বরূপ একটি ইমেল বিতরণ প্রোগ্রাম) জানে যে ফাইলটি মোড 600 দেওয়ার দরকার রয়েছে It কেবলমাত্র ব্যবহারকারী রয়েছে এমন গোষ্ঠীর সন্ধানের জন্য গ্রুপ ডাটাবেসটি অতিক্রম করতে হবে না - এবং এরকম গ্রুপ বা একাধিক না থাকলে কী করণীয়?

অন্য দিক থেকে আসা, ধরুন আপনি কোনও ফাইল দেখেন এবং আপনি এর অনুমতিগুলি নিরীক্ষণ করতে চান (অর্থাত্ তাদের কী হওয়া উচিত তা পরীক্ষা করুন)। আপনি যখন গ্রুপ সংজ্ঞাগুলি সনাক্ত করতে চান তার চেয়ে আপনি যখন "কেবলমাত্র ব্যবহারকারীর কাছে অ্যাক্সেসযোগ্য, সূক্ষ্ম, পরবর্তী" যেতে পারেন তখন এটি অনেক সহজ। (এই জাতীয় জটিলতা হ'ল সিস্টেমগুলির নিষ্ক্রিয়তা যা এসিএল বা সক্ষমতার মতো উন্নত বৈশিষ্ট্যগুলির ভারী ব্যবহার করে))

Orthogonality

প্রতিটি প্রক্রিয়া একটি নির্দিষ্ট ব্যবহারকারী এবং একটি নির্দিষ্ট গোষ্ঠী হিসাবে ফাইল সিস্টেমের অ্যাক্সেসগুলি সম্পাদন করে (আধুনিক ইউনিসে আরও জটিল নিয়ম সহ, যা পরিপূরক গোষ্ঠীগুলিকে সমর্থন করে)। রুট (ইউআইডি 0) এবং সিগন্যাল বিতরণ অনুমতি (ব্যবহারকারী-ভিত্তিক) পরীক্ষার সহ অনেকগুলি ব্যবহারকারীর ব্যবহার হয়। প্রক্রিয়া অনুমতিতে ব্যবহারকারী এবং গোষ্ঠীগুলির মধ্যে পার্থক্য এবং ফাইল সিস্টেমের অনুমতিগুলিতে ব্যবহারকারী এবং গোষ্ঠীর মধ্যে পার্থক্য করার একটি প্রাকৃতিক প্রতিসাম্য রয়েছে।

Comments

দুর্দান্ত উত্তর, এবং আমি বয়স্ক ব্যক্তির সম্পর্কে শিখতে উপভোগ করেছি। তবে, আপনি যা বলেছিলেন সে সম্পর্কে আমার কিছু সংরক্ষণ রয়েছে। একটি সহজ সিস্টেম, যা বাস্তবে এসিএল হিসাবে প্রায় (ঠিক না হলে) যতটা করতে পারে, প্রতিটি 'rwx' অনুমতিগুলিকে একটি গ্রুপ বহন করে (কাছাকাছি অন্য উপায়ের চেয়ে)। এটি হ'ল, আপনার একটি পঠন গোষ্ঠী, একটি লেখার গ্রুপ এবং একটি নির্বাহী গোষ্ঠী থাকবে। ওএসের উদ্দেশ্যে যদি সত্যিই প্রয়োজন হয় তবে আপনি কোনও মালিককে ফাইলের সাথে সংযুক্ত করতে পারেন। এইভাবে আপনি একটি বিশেষ 'মালিক' গ্রুপ এবং একটি 'প্রত্যেকে' গ্রুপও নির্দিষ্ট করতে পারেন। শ্রেণিবিন্যাস ব্যতীত, আমি মনে করি এটি সরলতা এবং অরথোগোনালিটি সহ সমস্ত কিছুকে কভার করে।

— ইয়ুভাল

@ ইউভাল আপনি যা বর্ণনা করছেন তা হ'ল একটি এসিএল সিস্টেম - কোনও ব্যবহারকারীর কাছে অনুমতি নির্ধারণের সরাসরি ক্ষমতা ব্যতীত লিনাক্সের সমান।

— গিলস 'এস-অশুভ হওয়া বন্ধ করুন'

এটা হতে পারে। আমি যা জোর দেওয়ার চেষ্টা করেছি তা হ'ল বর্তমানে প্রতিটি ফাইল রেকর্ডে দুটি আইডি (গোষ্ঠী, মালিক) এবং একটি বিটমাস্ক রয়েছে। কেবল চারটি আইডি রাখা কি আরও কার্যকর (আবার খরচ / উপার্জন যুক্তি) হয়ে উঠবে না? (গোষ্ঠী কার্যকর করুন, গ্রুপ পড়ুন, গ্রুপ লিখুন, মালিক)

— যুবাল

@ ইউভাল চারটি আইডি কেন? এটি এসিএলগুলির চেয়ে অনেক বেশি বিধিনিষেধযুক্ত হবে (কারণ আপনার প্রত্যেকটি গোষ্ঠীর জন্য একটি গ্রুপ সংজ্ঞায়িত করার জন্য রুটের প্রয়োজন হবে) এবং বর্তমান ইউনিক্স অনুমতিগুলির চেয়ে কমই কোনও নমনীয় (এক্সিকিউট থেকে পড়া আলাদা করা অত্যন্ত বিরল, এবং লেখার জন্য আপনি প্রায়শই চান পঠিত দল এবং লেখার গোষ্ঠীর মিলন)। আপনি যদি প্রতিটি অনুমতিের জন্য গোষ্ঠীর একটি তালিকা এবং ভাল পরিমাপের জন্য ব্যবহারকারীর একটি তালিকা মঞ্জুরি দেন (কারণ সর্বদা সঠিক গ্রুপ নেই, সমস্ত সিস্টেমে ব্যবহারকারী হিসাবে একটি গ্রুপ নেই) তবে আপনি মূলত সোলারিস / লিনাক্স এসিএল পেয়েছেন।

— গিলস 'অশুভ হওয়া বন্ধ করুন'

আপনি যুক্তি দিয়েছিলেন যে আমি যা বর্ণনা করেছি এটি একটি এসিএল, তবে এর অর্থ হ'ল বর্তমান লিনাক্স অনুমতি স্কিমটি একটি প্রতিবন্ধী এসিএল, যার কেবল একটির ব্যবহারকারী রেকর্ড, একটি গ্রুপ রেকর্ড এবং প্রত্যেকের জন্য একটি উইন্ডোজ (উইন্ডোজ লিঙ্গো ব্যবহারের জন্য) থাকতে পারে। আমি শব্দার্থবিজ্ঞানের পুনর্বিন্যাসের মাধ্যমে প্রতিবন্ধী-নেসে সংশোধন করার পরামর্শ দিয়েছি। সত্ত্বা নির্ধারণের পরিবর্তে অনুমতিগুলি লিখে দিন। এটি হতে পারে traditionalতিহ্যবাহী এসিএলগুলি কীভাবে প্রয়োগ করা হয় - আমি জানি না। মুল বক্তব্যটি হ'ল বর্তমান রাষ্ট্রের তুলনায় স্টোরেজ এবং সরলতার দিক থেকে এটি ন্যূনতম ব্যয় হিসাবে আসে, এখনও অরথোগোনাল তবে এসিএলগুলির সম্পূর্ণ অভিব্যক্তিপূর্ণ শক্তি সহ।

— যুবাল

Answer 2

এই ইচ্ছাকৃত নকশা বা একটি প্যাচ? তা হ'ল - মালিক / গোষ্ঠী অনুমতিগুলি কি কিছু যৌক্তিকতার সাথে একত্রে তৈরি এবং তৈরি করা হয়েছিল বা তারা কোনও প্রয়োজনের উত্তর দিতে একের পর এক এসেছিল?

কোনও ফাইলের ব্যবহারকারী / গোষ্ঠী / অন্যান্য অনুমতিগুলি মূল ইউনিক্স ডিজাইনের একটি অংশ।

এমন কোনও দৃশ্য আছে যেখানে ব্যবহারকারী / গোষ্ঠী / অন্যান্য স্কিম কার্যকর তবে একটি গোষ্ঠী / মালিকের প্রকল্পটি যথেষ্ট হবে না?

হ্যাঁ, কার্যত প্রতিটি দৃশ্য আমি কল্পনা করতে পারি যেখানে সুরক্ষা এবং অ্যাক্সেস নিয়ন্ত্রণ গুরুত্বপূর্ণ important

উদাহরণ: আপনি কোনও সিস্টেমে কিছু বাইনারি / স্ক্রিপ্ট দিতে পারেন কেবলমাত্র এক্সিকিউটিভ-এ কেবলমাত্র অ্যাক্সেস দিতে otherএবং পড়তে / লেখার অ্যাক্সেসকে সীমাবদ্ধ রাখতে পারেন root।

আমি নিশ্চিত না যে আপনি কেবলমাত্র ফাইল / সিস্টেমের অনুমতি সহ কোনও ফাইল সিস্টেমের অনুমতি মডেলটির জন্য যা মনে করছেন। আমি জানি না আপনি কীভাবে কোনও otherবিভাগের অস্তিত্ব ছাড়াই সুরক্ষিত অপারেটিং সিস্টেম রাখতে পারেন ।

সম্পাদনা: ধরা যাক আপনার এখানে group/otherঅনুমতিগুলি বোঝানো দরকার যা কেবল প্রয়োজন হবে, তারপরে আমি ক্রিপ্টোগ্রাফিক কীগুলি পরিচালনা করার জন্য কিছু উপায় তৈরি করার পরামর্শ দিচ্ছি বা কেবল সঠিক ব্যবহারকারীরা তাদের মেইল ​​স্পুলে অ্যাক্সেস করতে পারে এমন উপায় নির্ধারণ করার পরামর্শ দিচ্ছেন। এমন কেস রয়েছে যেখানে একটি ব্যক্তিগত কীটির কঠোর user:userমালিকানা প্রয়োজন হতে পারে তবে অন্যান্য ক্ষেত্রে যেখানে এটি user:groupমালিকানা দেওয়ার পক্ষে তা বোঝা যায় ।

প্রাইভেট ফাইল - ব্যবহারকারী হিসাবে একটি গ্রুপ তৈরি করে খুব সহজেই প্রাপ্তযোগ্য, এমন কিছু যা প্রায়শই অনেক সিস্টেমে হয়।

অনুমোদিত যে এটি সহজেই সম্পন্ন হয়েছে, তবে এটি একটি otherগোষ্ঠীর অস্তিত্বের সাথে ঠিক তত সহজেই সম্পন্ন হয়েছে ...

কেবলমাত্র একটি মালিককে (যেমন সিস্টেম পরিষেবা) কোনও ফাইলে লেখার অনুমতি দেওয়া, কেবলমাত্র একটি নির্দিষ্ট গোষ্ঠীটি পড়ার অনুমতি দেওয়া এবং অন্য সমস্ত অ্যাক্সেস অস্বীকার করা - এই উদাহরণটির সাথে সমস্যাটি হ'ল একবার প্রয়োজন হয় গ্রুপের লেখার অ্যাক্সেস পাওয়ার জন্য, ব্যবহারকারী / গোষ্ঠী / অন্যান্য এতে ব্যর্থ হয়। উভয়ের উত্তর হ'ল এসিএলগুলি ব্যবহার করা হচ্ছে এবং আইএমএইচও, মালিকের অনুমতিগুলির অস্তিত্ব প্রমাণ করতে পারে না।

আমি আপনার বিবৃতিটির অংশটি হাইলাইট করেছি যা otherইউনিক্স ফাইল সিস্টেমের অনুমতিগুলির মধ্যে একটি বিভাগের জন্য যৌক্তিক প্রয়োজনীয়তা সম্পর্কে আমার বক্তব্য পুনরুক্ত করে বলে মনে হচ্ছে ।

আপনি যেমন মনে করছেন এমন ফাইল সিস্টেমের নকশাটি অনিরাপদ বা অযৌক্তিক হতে পারে I ইউনিক্স কিছু খুব স্মার্ট লোক দ্বারা ডিজাইন করা হয়েছিল এবং আমি মনে করি তাদের মডেল সুরক্ষা এবং নমনীয়তার সর্বোত্তম সম্ভাব্য ভারসাম্য দেয়।

Comments

আমি মনে করি "গোষ্ঠী / মালিক" টাইপ ছিল "গ্রুপ / অন্যান্য" হওয়ার উদ্দেশ্যে

— র্যান্ডম 832

আহ, আপনি সম্ভবত ঠিক আছেন! সেক্ষেত্রে আমি আরও একটি পাল্টা উদাহরণ যুক্ত করব।

— চার্লস বয়ড

আপনি যেমন পড়তে পারেন The UNIX Time-Sharing System, 1974 সালে ডেনিস এম রিচি এবং কেন থমসনের লেখা, মূলত অনুমতিগুলির জন্য 7 টি বিট ছিল: Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users.(সপ্তম বিটটি ছিল setuidবিট)।

— কার্লোস ক্যাম্পার্ডার্স

Answer 3

এই ইচ্ছাকৃত নকশা বা একটি প্যাচ? তা হ'ল - মালিক / গোষ্ঠী অনুমতিগুলি কি কিছু যৌক্তিকতার সাথে একত্রে তৈরি এবং তৈরি করা হয়েছিল বা তারা কোনও প্রয়োজনের উত্তর দিতে একের পর এক এসেছিল?

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

এমন কোনও দৃশ্য আছে যেখানে ব্যবহারকারী / গোষ্ঠী / অন্যান্য স্কিম কার্যকর তবে একটি গোষ্ঠী / মালিকের প্রকল্পটি যথেষ্ট হবে না?

আমি সাধারণত ফাইল অ্যাক্সেসের জন্য ব্যবহার করি সেগুলি হ'ল: (আমি সরলতার জন্য বিট মানগুলি ব্যবহার করছি এবং কারণ আমি সাধারণত সেগুলি সেট করি))

• 600বা 400: ব্যবহারকারীর কেবল অ্যাক্সেস (এবং হ্যাঁ আমি কেবল ব্যবহারকারীর পাঠ্য অ্যাক্সেসের অনুমতি দিই না)।
• 640বা 660: ব্যবহারকারী এবং গোষ্ঠী অ্যাক্সেস।
• 644, 666বা 664: ব্যবহারকারী, গোষ্ঠী এবং অন্যান্য অ্যাক্সেস। যে কোনও দুটি স্তরের অনুমতি স্কিম কেবল এই তিনটি ক্ষেত্রে পরিচালনা করতে পারে। তৃতীয়টির জন্য এসিএল লাগবে।

ডিরেক্টরি এবং প্রোগ্রামগুলির জন্য আমি সাধারণত ব্যবহার করি:

• 700বা 500: ব্যবহারকারী কেবল অ্যাক্সেস
• 750বা 710: কেবলমাত্র গ্রুপ অ্যাক্সেস
• 755, 777, 775, অথবা 751: ব্যবহারকারী, গ্রুপ, এবং অন্যান্য অ্যাক্সেস। একই মন্তব্য ফাইল হিসাবে প্রয়োগ করা হয়।

উপরেরটি সর্বাধিক ব্যবহৃত হয় তবে আমি ব্যবহার করা অনুমতি সেটিংসের সম্পূর্ণ তালিকা নয়। একটি গোষ্ঠীর সাথে মিলিত উপরের অনুমতিগুলি (কখনও কখনও ডিরেক্টরিগুলিতে স্টিকি গ্রুপ বিট সহ) সমস্ত ক্ষেত্রেই আমি যথেষ্ট হয়েছি যেখানে আমি এসিএল ব্যবহার করেছি।

যেমন উপরে উল্লিখিত হয়েছে, ডিরেক্টরি তালিকাতে অনুমতিটি তালিকাভুক্ত করা খুব সহজ। যদি এসিএলগুলি ব্যবহার না করা হয় তবে আমি কেবলমাত্র একটি ডিরেক্টরি তালিকা দিয়ে অ্যাক্সেস অনুমতিগুলি অডিট করতে পারি। আমি যখন এসিএল ভিত্তিক সিস্টেমগুলির সাথে কাজ করি, তখন অনুমতিগুলি যাচাই বা নিরীক্ষণ করা আমার পক্ষে খুব কঠিন।

Answer 4

ACL গুলি উদ্ভাবনের আগে ব্যবহারকারী / গোষ্ঠী / অন্যান্য অনুমতি ব্যবস্থা নকশা করা হয়েছিল। এটি ইউনিক্সের প্রথম দিনগুলিতে ফিরে যায়, সুতরাং আপনি বলতে পারবেন না এসিএল দিয়ে সমস্যাটি সমাধান করা উচিত। এমনকি যদি এসিএলের ধারণাটি সুস্পষ্ট বলে মনে হয়, তবে এটি নির্দিষ্ট ফাইলের পরিবর্তে প্রতিটি ফাইলের সাথে ভেরিয়েবলের অনুমতি সম্পর্কিত তথ্য সংরক্ষণ এবং পরিচালনা করতে একটি উল্লেখযোগ্য [দিনের জন্য] অতিরিক্ত পরিমাণে জড়িত থাকতে পারে।

প্রতিটি কিছুর জন্য এসিএল ব্যবহার করার অর্থ হল আপনার কাছে অনুমতি সম্পর্কিত তথ্যের একটি সু-সংজ্ঞায়িত উপসেট নেই যা "এক নজরে" দেখানো যেতে পারে। আউটপুট ls -lস্ট্যান্ডার্ড (ব্যবহারকারী / গোষ্ঠী / অন্যান্য) অনুমতি, ব্যবহারকারী এবং গোষ্ঠীর নাম এবং এন্ট্রিগুলির সাথে একটি অতিরিক্ত নোটেশন (উদাহরণস্বরূপ +বা @সাইন) দেখায় যাগুলির সাথে একটি এসিএল যুক্ত রয়েছে, সমস্তই এক লাইনে। আপনার সিস্টেমের সমতুল্য কার্যকারিতা সরবরাহ করতে এসিএলে "শীর্ষ দুটি" গোষ্ঠীগুলি সনাক্ত করা প্রয়োজন।

একটি অতিরিক্ত পয়েন্ট হিসাবে, একটি ফাইল এখনও প্রয়োজন আছে ইউনিক্স মডেল একজন মালিক কারণ ইউনিক্স ACLs যারা ACL এর সংশোধন করার অনুমতি দেওয়া হয় প্রদান করবেন না।