সুডো বনাম রুট; কোন বাস্তব পার্থক্য?


44

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

sudo -l

আমি পাই:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

লিনাক্স / সার্ভার টিমের কাছ থেকে প্রকৃতপক্ষে রুট হওয়ার অ্যাক্সেস পাওয়া কোনও বুদ্ধিমান প্রক্রিয়া নয়, তাই আমি সেগুলি নিজেই ইনস্টল করতে পছন্দ করব।

কোনও সার্ভারে সফ্টওয়্যার ইনস্টল করার জন্য সুডো রুটের চেয়ে আলাদা আচরণ করবে এমন কোনও ব্যবহারিক কারণ রয়েছে কি?


2
আমার মনে হয় আপনার এটিকে ফিরিয়ে দেওয়া উচিত। অন্যরা যেমন দেখিয়েছে, সুডো ব্যবহার করে শিকড় অর্জনের এক অজস্র উপায় রয়েছে এবং সুডো অপর্যাপ্ত কেন সে বিষয়ে যদি আপনাকে কোনও দৃ concrete় কারণ প্রদান করতে না পারে তবে তার পক্ষে দাঁড়াতে কোনও পা নেই।
গ্যারেট

1
পরিবেশ এবং সাবকম্যান্ডগুলি মাথায় আসে। আমি মনে করি হাস্তুর পরিবেশের সাথে একটি ভাল কাজ করেছে, এবং জয়ন সাবকম্যান্ড, পাইপিং এবং পুনঃনির্দেশ সহ খুব ভাল কাজ করেছে।
jww

2
গ্যারেটের একটি ভাল বক্তব্য রয়েছে, তবে আমি সম্ভাব্য পিসিং প্রতিযোগিতায় আসার আগে আমি সমর্থন সদস্যকে জিজ্ঞাসা করব: আপনি কি এটি উভয় উপায়ে চেষ্টা করে দেখেছেন এবং সেগুলির মধ্যে একটিতেও এটি ব্যর্থ হয়েছে? sudoস্ক্রিপ্টগুলি বর্তমানে লিখিত আছে বলে তিনি ব্যর্থতার রাস্তায় এবং স্ক্রিপ্টগুলিতে নামতে পারেন । যদি সেই ক্ষেত্রে, তারপর এসডিএস 'উত্তর আপনার কাছে সবচেয়ে সহায়ক হতে পারে: sudo su -
jw

উত্তর:


34

এটা দৃঢ়ভাবে কিভাবে আপনার সাথে আপনার প্রোগ্রাম কল উপর নির্ভর করে sudoবা su
যেমন এই সিস্টেমে আমি এই মুহুর্তে রয়েছি:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1] 

যেখানে [1] = / usr / স্থানীয় / এসবিন: / usr / স্থানীয় / বিন: / usr / sbin: / usr / bin: / sbin: / বিন
এনভ = পরিবেশের ভেরিয়েবলগুলি 1 এবং 5 -র জন্য পুনরায় সেট করা হয়, এতে $ USER থেকে নেওয়া হয় 2,3,4।

একটি স্ক্রিপ্ট, বা যে একটি ভিন্ন বিকল্প বিভিন্ন দেখতে পারেন সঙ্গে চালু একটি প্রোগ্রাম তাই $PATH, $HOMEতার শেল বিভিন্ন পড়তে পারেন .bashrc, .profileএনভায়রনমেন্ট ভেরিয়েবল এবং। এটি এর সাথে সম্পর্কিত ফাইলটি পড়ে $HOME। প্রতিটি ব্যবহারকারী তার পরিবেশকে বিভিন্ন উপায়ে পরিবর্তন করতে পারে (ভেরিয়েবল $PATH,, .Bashrc,। প্রোফাইল, .ব্যাশ_প্রোফাইল, ওরফে ...)। বিশেষত ব্যবহারকারীর নিজস্ব ডিরেক্টরিতে আলাদা আলাদা ক্রম থাকতে পারে $PATHএবং ফলস্বরূপ, একটি স্ক্রিপ্ট একটি কমান্ড কার্যকর করতে পারে যেমন /home/$USER/binপরিবর্তে তারপরে মূল থেকে প্রত্যাশিত পথে।

আপনি sudo -iযেমনটি রুট হিসাবে লগইন করেছেন তে আপনি প্রোগ্রামটি চালিয়ে su -যেতে পারেন তবে আপনি যদি এটির সাথে sudo MyCommandবা এর সাথে চালনা করেন তবে আপনার আলাদা আচরণ থাকতে পারে su -c MyCommand


থেকে man su:

বর্ণনার অংশে:
বর্তমান পরিবেশটি নতুন শেলের কাছে চলে গেছেUsers PATH এর মান / ব্যবহারকারীদের জন্য / বিন: / usr / বিন, বা / sbin: / বিন: / usr / sbin: / usr / বিনকে সুপারসারের জন্য পুনরায় সেট করা হয়
...
বিকল্প অংশে:
- , -l , --login ব্যবহারকারীর প্রত্যাশার মতো
একটি পরিবেশ সরবরাহ করুন যা ব্যবহারকারী সরাসরি লগ ইন করে

মানুষ থেকে sudo

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


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

23

আপনার যদি সম্পূর্ণ sudoঅ্যাক্সেস থাকে তবে আপনি rootব্যবহার করতে পারেন sudo su -, তাই সুরক্ষা পয়েন্টটি মোট।

আসলে, কোনও প্রোগ্রামের মধ্যে পার্থক্যটি সনাক্ত করার একটি উপায় রয়েছে rootএবং বনাম - sudoব্যবহার করে একটি প্রোগ্রাম চালিত হয় তবে এটি একটি স্বীকৃত কৌশল। প্যাচ সিস্টেম কেন এটি করবে?getuidgeteuid


5
কথা বললে su -, তিনি sudo -iসম্ভবত এটি ব্যবহার করতে চান যাতে সরাসরি লগ ইন করার সময় তার মতো পরিবেশ থাকে।
ক্রিশ্চিয়ান সিউপিতু

2
আপনি যদি উদাহরণস্বরূপ চালনা করেন তবে আপনি sudo myscriptযে শেলটিতে রয়েছেন তা থেকে $ PATH এবং পরিবেশের পরিবর্তনগুলি রাখবেন will আপনি যদি দৌড়েন তবে আপনি চালাবেন sudo -i myscriptযেন আপনি মূল হিসাবে লগইন করেন। আমাদের _zoo কলগুলির
হাস্তুর

1
আমি মনে করি এটি উল্লেখ করা গুরুত্বপূর্ণ যে পরিবেশগত পরিবর্তনশীলগুলি sudoরুট হিসাবে লগ ইন করার জন্য একই সেটআপ নাও হতে পারে
সিক্রেটফর্মুলা

1
@ ডম্যানেক্স: সুডো সুপারজারের পক্ষে দাঁড়ায় না, এটি "সুইজার ইউজার ডু" do su এবং sudo কেবলমাত্র সুপারভাইজারের পরিবর্তে যে কোনও ব্যবহারকারীর স্যুইচ করতে ব্যবহার করা যেতে পারে। এছাড়াও সুডো সম্পর্কে সিউডো কিছুই নেই, সুডো চলতে গিয়ে আপনি আসল মূলটি পাবেন কিছু নকল কিছু না। নোট করুন যে সুডোর যাদুটি সত্যই নির্ধারিত অনুমতি বিট থেকে আসে।
মিথ্যা রায়ান

2
এসডিএস, @ চার্লসডুফি: সুডো এবং সু কারণ geteuid()এবং getuid()একে অপরের থেকে আলাদা হওয়ার ধারণাটি একটি মিথ। su এবং sudo নির্দিষ্ট কমান্ড বা শেল চালানোর আগে লক্ষ্য ব্যবহারকারীদের কাছে আসল এবং কার্যকর ব্যবহারকারী আইডি উভয়ই পরিবর্তন করে দেয়, খুব অস্বাভাবিক পরিস্থিতিতে যে আপনি স্পষ্টভাবে অন্যথায় আচরণের জন্য তাদেরকে কনফিগার করেছেন config আপনি এটি (সুডোর জন্য) চালিয়ে sudo id -uএবং sudo id -ru(উভয় 0 টি দেখিয়ে), সুডো (8) পড়ে ( কম্যান্ড এক্সিকিউশনের অধীনে ) পড়া বা একটি পরীক্ষা প্রোগ্রাম লিখে যাচাই করতে পারেন

7

@ হস্তুর দ্বারা চিহ্নিত হিসাবে আপনি যদি একটি রুট শেল পেয়ে থাকেন তবে কয়েকটি পার্থক্য রয়েছে।

আপনি যদি একটি রুট শেল না পেয়ে থাকেন তবে আরও পার্থক্য রয়েছে। সমর্থন সদস্য অভিজ্ঞতা মত কাজগুলি করার চেষ্টা থাকতে পারে sudo patch -p0 < /root/patch.fileযেখানে patchরুট হিসাবে চালাতে, কিন্তু <(একটি ফাইল থেকে বংশীধ্বনিতুল্য) নয়।


1
ডান: ব্যবহারিক দৃষ্টিকোণটি প্রায়শই এমন ইঙ্গিত দেয় যা কেবল ম্যান পৃষ্ঠাগুলি থেকে পাওয়া শক্ত spot অনুরূপ পরিস্থিতি কাটিয়ে উঠতে আপনি আরও জিম করতে বাধ্য হন [:-)] যেমন কিছু লিখুন sudo /bin/bash -c "./patch -p0 < /root/patch"। আপনি যখন ফাইল তৈরির জন্য পুনর্নির্দেশটি ব্যবহার করেন তখন আরও নাজুক হয় >। প্রথম উপায়ে আপনি এমন একটি ফাইল তৈরি করবেন যা ব্যবহারকারীর অন্তর্গত তবেই যদি আপনার চূড়ান্ত ডিরেক্টরিতে লেখার যথেষ্ট অধিকার থাকে। পরবর্তী পদ্ধতিতে আপনি রুটের মালিকানাধীন একটি ফাইল তৈরি করবেন ... ইউনিক্সের অন্ধকার দিক ;-)
হাস্তুর

1

আমি সুডো অ্যাক্সেস ব্যবহার করার সময় বিলেভ করি, একটি লগ ফাইল তৈরি করা হয়, তবে রুট অ্যাক্সেসের মাধ্যমে সরাসরি চলার সময় সেখানে নেই।


0

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.