উবুন্টু যখন কোনও প্রশাসকের ব্যবহারকারীর পাসওয়ার্ড জিজ্ঞাসা করেন, তখন কোন প্রশাসনিক ব্যবহারকারীকে জিজ্ঞাসা করবেন তা কীভাবে সিদ্ধান্ত নেবে?

Question

আমি একটি উবুন্টু (10.10) মেশিন স্থাপন করছি যা বেশ কয়েকজন লোক ব্যবহার করবে। এটি একটি ছোট অফিসে একটি ভাগ করা মেশিন। এর প্রাথমিক ভূমিকাগুলি ভার্চুয়ালবক্সের সাথে ভার্চুয়াল মেশিনগুলি হোস্ট করছে এবং সাম্বার সাথে ফাইলগুলি সরবরাহ করছে।

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

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

সংক্ষেপ:

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

এখানে কাঙ্ক্ষিত রাষ্ট্রটি আনতে আমার কোন কনফিগারেশন পরিবর্তন করতে হবে?

Comments

একটি বিকল্প হ'ল ভার্চুয়ালাইজেশন সম্পর্কিত কমান্ডগুলি স্বয়ংক্রিয়ভাবে অ্যাডমিন সুবিধাদি ব্যবহার করতে দেয় allow আমি নিশ্চিত যে আমি একটি প্রশ্ন পড়েছি, কিন্তু আমি ভুলে গিয়েছিলাম।

— অক্সভিভি

একটি দ্রুত গুগলিং আমাকে বলেছে আপনি এটি খুব একই sudoersফাইলটি থেকে করেন , আপনি আরও তথ্যের জন্য এটির ম্যানপেজ পরীক্ষা করতে পারেন ।

— অক্সভিভি

আমি বিবেচনা করেছি যে আমি যখন সম্পাদনা করছিলাম sudoers: সুরক্ষা উদ্বেগের কারণে এটি কোনও প্রথম অবলম্বন নয়। এনজোটিবের উত্তরও দেখুন - সমস্যার একটি অংশ ছিল পলিসিকিটের মধ্যে বিভ্রান্তি sudo।

— ব্রিইড ম্যাকডোনেল

Answer 1

প্রথমে এটি চিহ্নিত করতে দিন যে দুটি পৃথক ব্যবস্থার মাধ্যমে একটি অ-রুট ব্যবহারকারীর জন্য সুবিধাজনক ক্রিয়াকলাপ অনুমোদিত ।

1. sudo

2. PolicyKit- র

প্রথমটি ব্যবহৃত হয় যখন আপনি স্পষ্টভাবে একটি কমান্ড চালিত করেন sudoবা একটি মেনু আইটেম যার কমান্ডটি gksu(যেমন সিনাপটিক প্যাকেজ ম্যানেজারের সাথে ) মোড়ানো থাকে ।
এই ক্ষেত্রে প্রয়োজনীয় পাসওয়ার্ডটি হ'ল আমন্ত্রণকারী ব্যবহারকারীর, সাধারণত ব্যবহারকারী লগইন হয়।

দ্বিতীয়টি ব্যবহৃত হয় যখন কোনও পলিসিকিট-সচেতন অ্যাপ্লিকেশন কোনও সুবিধাযুক্ত ক্রিয়া সম্পাদনের চেষ্টা করে। সেক্ষেত্রে অ্যাপ্লিকেশনটি পলিসিকিট স্থানীয় কর্তৃপক্ষকে (ডি-বাসের মাধ্যমে) জিজ্ঞাসা করে যদি এই পদক্ষেপ কার্যকর করা যায়। স্থানীয় কর্তৃপক্ষ তারপরে একটি প্রমাণীকরণ এজেন্টের মাধ্যমে সক্রিয় ব্যবহারকারীকে তার পরিচয় প্রমাণ করতে বলে। ডায়ালগ উইন্ডোগুলি নিম্নলিখিতগুলির মতো (দুর্ভাগ্যক্রমে ইতালীয় পাঠ্য সহ :)

আপনি সামান্য কালো ত্রিভুজ এবং লেবেল বিশদ থেকে পলিসিকিট সনাক্ত করতে পারেন । যেমন আপনি দেখতে পাচ্ছেন, adminগ্রুপে আরও একজন ব্যবহারকারী রয়েছেন তবে প্রমাণীকরণের জন্য কোন ব্যবহারকারীকে ব্যবহার করবেন তা আপনি তালিকা থেকে বেছে নিতে পারেন।

এই সমস্ত দেওয়া, উভয়ই sudoপলিসিকিট আরও জটিল, যা অর্জন করা যায় এমন কনফিগারেশনের ক্ষেত্রে: আপনি এমন ক্রিয়াটি কনফিগার করতে পারেন যা পাসওয়ার্ড ছাড়াই কার্যকর করা যায়, কেবলমাত্র কোনও নির্দিষ্ট ব্যবহারকারী বা গোষ্ঠী দ্বারা চালানো ইত্যাদি etc.

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

অ্যাপ্লিকেশন দ্বারা ব্যবহৃত প্রক্রিয়াটি যখন sudo(জিইউআইয়ের মাধ্যমে সম্পাদিত প্রশাসনিক কাজের জন্য এটি কম ঘন ঘন হয়ে উঠছে) হয়ে থাকে, তখন প্রমাণীকরণের জন্য আপনাকে ব্যবহারকারী চয়ন করার কোনও তাত্ক্ষণিক এবং সহজ উপায় নেই have

Comments

আমার মনে হচ্ছে পরিস্থিতি সম্পর্কে আমার আরও ভাল বোঝা আছে। ধন্যবাদ.

— ব্রিইড ম্যাকডোনেল

Answer 2

স্পষ্টতই, sudoএই ক্ষেত্রে আমার জন্য প্রথম পছন্দ হবে। প্রধান বিন্দু প্রদর্শিত হয় হতে যে অধিকাংশ (ACTUAL) প্রশাসক আসলে ব্যবহার করবেন না /etc/sudoersতার fullest সম্ভব পরিমাণে ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias)।

বেশিরভাগ অ্যাডমিনগুলি কেবলমাত্র বিদ্যমান কিছু নিয়ম ব্যবহার করে এবং ব্যবহারকারীদের যুক্ত করা বা আরও খারাপভাবে কেবল সেই sudoগ্রুপে ব্যবহারকারীদের যুক্ত করে যার জন্য উবুন্টু সেটআপগুলিতে ( %sudo...) নিয়ম উপস্থিত থাকে । এটি অবশ্যই সম্পর্কিত ব্যবহারকারীদের বিনামূল্যে রাজত্ব এবং সুপারউসার অ্যাকাউন্টের সম্পূর্ণ ক্ষমতা দেয়।

আপনার মন্তব্য দেওয়া:

তাই আমি তাদের এগুলিতে যুক্ত করেছি /etc/sudoers

আমি মনে করি আপনি এটিকে যতটা সম্ভব ব্যবহার করবেন না।

আপনার মতো একটি দৃশ্যে আমি ববকে সীমাবদ্ধ করার জন্য যে কয়েকটি ক্রিয়াটি আক্ষরিক অর্থে স্ক্রিপ্ট করব। হোস্টে দু'জন নির্দিষ্ট ব্যবহারকারীকে কোনও নির্দিষ্ট কেভিএম অতিথিকে পুনরায় বুট করার অনুমতি দেওয়ার জন্য, আমি যে সার্ভারটি রক্ষণ করি তাতে এটিই হয়েছিল। স্ক্রিপ্টগুলিতে দোভাষীর নিখুঁত পথ সহ একটি হ্যাশবাং থাকবে (উদাহরণস্বরূপ #!/bin/dashপরিবর্তে #!/usr/bin/env bash) এবং সম্ভবত একটি শেল দিয়ে চালানো হবে যা সুবিধাযুক্ত কাজের জন্য ( /bin/dashবা /bin/sh) অন্য কোথাও ব্যবহৃত হয় । সেগুলি কেবল সতর্কতা। এগুলি ব্যতীত, আমি বাইনারিগুলির সমস্ত নিখুঁত পাথগুলিকে হার্ডকোড করা এবং যতটা সম্ভব সম্ভব কয়েকটি ব্যবহার করা নিশ্চিত করব। উদাহরণস্বরূপ bash/ ব্যবহার করার সময় dashআমি builtinওভার commandগুলি এর চেয়ে বেশি পছন্দ করি (দেখুন man bash)। কোনও ভেরিয়েবলকে পরম পথ নির্ধারণ করে এবং সেই চলকের উপর ভিত্তি করে প্রোগ্রামটি উল্লেখ করে আপনি এটি রক্ষণাবেক্ষণযোগ্য করতে পারেন ($VIRSHপরিবর্তে /usr/bin/virsh)। যদি আপনি পারেন তবে যে কোনও বাহ্যিক স্ক্রিপ্টগুলির কল করার আগে তাদের কোডটি পরীক্ষা করুন। বিশেষত যদি আপনার কোনও সুবিধাভোগী প্রসঙ্গে কল করতে হয়। আমার ক্ষেত্রে আমি ব্যবহারকারীদের একটি নির্দিষ্ট মূল ডিরেক্টরি এবং একটি বিশেষ এসএসএইচ সাবসিস্টেমের মধ্যেও সীমাবদ্ধ রাখি কারণ তারা কেবলমাত্র মেশিনে sshdএবং পাবলিক কী প্রমাণীকরণের মাধ্যমে সংযুক্ত থাকে । অবশ্যই আপনার দরকার নেই।

chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>কাউকে প্রতিরোধ করতে ভুলবেন না তবে rootএটির সাথে ঝুঁকিপূর্ণ থেকে রক্ষা করুন । এছাড়াও সঙ্গে সতর্কতা অবলম্বন করা setuidএবং setgidবিট লক্ষ্য বাইনেরিতে সক্রিয় ( findতাদের স্পট করতে ব্যবহার করা যেতে পারে)। আসুন সেই মুহুর্তের জন্য ধরে নেওয়া যাক যেখানে আপনার স্ক্রিপ্টটি থাকে /usr/sbin/priv-action।

এখন আপনার সম্পাদনা করুন /etc/sudoers। noexecসুস্পষ্টভাবে অনুমতিপ্রাপ্তদের চেয়ে অন্যান্য বাইনারি প্রতিরোধে ব্যবহার করা যেতে পারে। এখানে অতিরিক্ত বর্ণনা রয়েছে যা কেবলমাত্র আমি এখানে বর্ণনা করছি। সুতরাং পরামর্শ নিশ্চিত করুন man sudoers।

এখন আমি User_Aliasআমার sudoersফাইলে ব্যবহারকারীদের ( ) নামকরণ করতে পছন্দ করি তবে আপনি ঠিক Group_Alias( man sudoers) বা একটি প্রকৃত সিস্টেম গ্রুপ (উদাহরণস্বরূপ %sudo) ব্যবহার করতে পারেন:

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

এবং তারপরে সেই নির্দিষ্ট স্ক্রিপ্টটি কার্যকর করার জন্য একটি কমান্ড ওরফে যুক্ত করুন:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

স্ক্রিপ্টের মাধ্যমে সুবিধাপ্রাপ্ত কমান্ডগুলি কার্যকর করতে bob(বা বরং এর নীচে তালিকাভুক্ত ব্যবহারকারীদের LIMITED_ADMINS) অনুমতি দেওয়ার জন্য যাদু লাইনটি সর্বশেষে আসে না :

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

পূর্ববর্তী ওরফে সংজ্ঞাগুলির মতো নয় যে রেখার জন্য একটি ব্যাখ্যা প্রয়োজন। সুতরাং আসুন প্রথমে একটি "ব্যবহারকারী নির্দিষ্টকরণ" রেখার মধ্য দিয়ে অংশগুলি খনন করি। এখানে man sudoersসহায়তা করে:

ব্যবহারকারীর নির্দিষ্টকরণের মূল কাঠামোটি who where = (as_whom) what।

উদাহরণ লাইন (বেশিরভাগ উবুন্টু সেটআপে পাওয়া যায়):

root    ALL=(ALL) ALL

এই একটি ব্যবহারকারী বলেছেন নামে root (ব্যবহারের #0ইউআইডি তা গিঁট 0) হতে পারে, সব হোস্টে, যেকোনো ব্যবহারকারী প্রেক্ষাপটে কিছু অধীনে চালানো কিন্তু তার পাসওয়ার্ড জানতে চাওয়া হবে (ডিফল্ট আচরণ অভিমানী)। NOPASSWDশেষের আগে ট্যাগ যুক্ত করার ALLপরে rootপাসওয়ার্ড না চাওয়া ছাড়াই এটি করার অনুমতি দেওয়া হবে (যেমন root ALL=(ALL) NOPASSWD:ALL:)। ALLবিভিন্ন এলিফ প্রকারের জন্য একটি অভ্যন্তরীণ ওয়াইল্ডকার্ড ওরফে।

তবে বব ফিরে:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

bobএবং অন্যান্য তালিকাভুক্ত সদস্যদের User_Alias LIMITED_ADMINSচালানোর অনুমতি দেয় (সমস্ত হোস্টে, এটি যা এর ALLজন্য) ব্যবহারকারী হিসাবে root(গোষ্ঠীটির বর্ণিত , তবে দেওয়া যেতে পারে, দেখুন man sudoers) এর মধ্যে দেওয়া কমান্ডগুলি Cmnd_Alias PRIV_ACTION। এটা ভালো হচ্ছে. তবুও ধরে নিচ্ছেন যে আপনি এই স্ক্রিপ্টটি লিখেছেন, আপনি বিভিন্ন পরামিতিগুলিকে মঞ্জুরি দিতে পারবেন, যার ফলে একাধিক স্ক্রিপ্টগুলি লিখতে এড়ানো হবে। /etc/sudoersআর্গুমেন্টগুলি পাস করার অনুমতি দেওয়া সীমাবদ্ধ করতে আনন্দের সাথে শেলের মতো ওয়াইল্ডকার্ড নেয়।

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

আপনি সমস্ত ধরণের সংশ্লেষ নিয়ে আসতে পারেন - যা সুরক্ষার দিকটি হুবহু সহায়তা করতে পারে না - আপনার নির্দিষ্ট ক্ষেত্রে সমাধানের জন্য, তবে একবার আপনি যখন আপনার মৌলিক শব্দভাণ্ডারটি কথা বলেন তবে /etc/sudoersবেশ জাদুতে অভিনয় করতে পারবেন :)

নোট: মনে রাখবেন যে আপনি /etc/sudoers.d/যদি খুব ঝোঁক বোধ করেন তবে নীচে একটি নতুন ফাইলও তৈরি করতে পারেন । এটি আপনার /etc/sudoersলাইনটি ধারণ করে:

#includedir /etc/sudoers.d

Answer 3

ইউনিক্স / লিনাক্সে কেবলমাত্র একটি সুপার ব্যবহারকারী রয়েছেন, এর নামটি মূল, তবে sudoers এমন ব্যবহারকারী যাঁরা রুট হয়ে উঠতে পারেন। আপনার গ্রুপগুলি ব্যবহার করা উচিত:

newgrp admins

এবং তারপরে ব্যবহারকারীদের সেই গোষ্ঠীতে নিয়োগ করুন:

chgrp alice admins

তারপরে sudoers কনফিগারেশনের ফাইলগুলিতে অ্যাডমিনদের গোষ্ঠীটি যুক্ত করুন যদি গ্রুপটি ব্যবহারকারী ছিল।

হালনাগাদ

অথবা আপনি যে কোনও ব্যবহারকারীকে প্রশাসক গোষ্ঠীতে যুক্ত করতে পারেন:

chgrp alice admin

Comments

দুঃখিত আমি ট্যাব কী টিপুন এবং এটি শেষ না করে পাঠিয়েছি

— ফ্রান্সিসকো ভালাদেজ

অসম্পূর্ণ উত্তরের ভিত্তিতে জোরচেড মন্তব্য। বর্তমান উত্তরটি চেষ্টা করে দেখছি। ধরে নিই যে অতিরিক্ত স্পেসিফিকেশন ভবিষ্যতের পাঠকদের জন্য সম্ভবত সিসাদমিন কাজের সাথে কম পরিচিত হবে।

— ব্রিহিড ম্যাকডোনেল

অবশ্যই আমি ধৃষ্ট হতে বোঝানো হয়নি, সেখানে প্রায় এক stackexchange সাইট sysadmin

— ফ্রান্সিসকো ভ্য়াল্দেজ

আমি জানি সার্ভারফল্ট বিদ্যমান। আমি এখানে জিজ্ঞাসা করছি কারণ এটি একটি উবুন্টু-নির্দিষ্ট আচরণ।

— ব্রিহিড ম্যাকডোনেল

আমি যতদূর জানি: adduser <user>, addgroup <group>এবং adduser <user> <group>Debian / Ubuntu- উপর পছন্দের উপায়।

— 0xC0000022L