রুট করার সময় systemctl অ্যাক্সেস অস্বীকার করা হয়

Question

আমি যখন দৌড়ান

sudo systemctl disable avahi-daemon.socket

আমি পাই

Failed to execute operation: Access denied

তবে এটি রুট হিসাবে চালানো হয়েছে, অ্যাক্সেসকে কীভাবে অস্বীকার করা যেতে পারে? (সেন্টস 7)

Comments

আপনি কি ডকার বা এলএক্সসি বা এলএক্সডি এর মতো কোনও পাত্রে চালাচ্ছেন? আপনি কি নিশ্চিত যে আপনি কোনও ধারকটিতে আছেন বা নেই?

— allquixotic

ভার্চুয়ালবক্সে আমি একটি নতুন CentOS ইনস্টল চালাচ্ছি। এটি একটি ধারক হিসাবে গণনা না?

— স্প্রাফ

না, ভার্চুয়ালবক্স কোনও ধারক নয়, এটি একটি ভার্চুয়াল মেশিন। তারা মৌলিকভাবে পৃথক। সম্ভবত এটি journalctl -xeকেন ঘটছে তা বোঝার জন্য আপনাকে দৌড়াতে হবে।

— allquixotic

নোট করুন যে এই ত্রুটি বার্তাটি ("ক্রিয়াকলাপ চালাতে ব্যর্থ: অ্যাক্সেস প্রত্যাখ্যান করা হয়েছে") যখন প্রয়োগকারী মোডে অ-বিদ্যমান পরিষেবা অ্যাক্সেস করার চেষ্টা করার সময়ও ঘটতে পারে। অনুমতি মোডে আপনি "অপারেশন চালাতে ব্যর্থ: এই জাতীয় কোনও ফাইল বা ডিরেক্টরি নেই"।

— ডানমিচেলো

Answer 1

আমি সেন্টস 7-তেও কাজ করি এবং একই রকম সমস্যা ছিল:

# systemctl unmask tmp.mount
Failed to execute operation: Access denied

অস্বীকারটি সেলইনাক্সের সাথে সম্পর্কিত। আপনি যদি SELinux enforcingমোডে চালাচ্ছেন তবে এটি আপনার ক্ষেত্রে হতে পারে :

# getenforce
Enforcing

আমার ক্ষেত্রে, systemctlত্রুটিটি USER_AVCসেলইনাক্স লগ ফাইলে একটি অস্বীকৃতি তৈরি করেছিল /var/log/audit/audit.log:

type=USER_AVC msg=audit(1475497680.859:2656): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { enable } for auid=0 uid=0 gid=0 path="/dev/null" cmdline="systemctl unmask tmp.mount" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:null_device_t:s0 tclass=service  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

সমাধান

এই নিবন্ধটিতে বলা হয়েছে যে এটি সিস্টেমেড বাগের কারণে এবং চারপাশে একটি কাজ সরবরাহ করে:

systemctl daemon-reexec

গৌণ সমাধান

উপরেরটি যদি কাজ না করে তবে আপনি সেলইনক্স মোডটি এতে সেট করতে পারেন permissive:

setenforce 0

এবং এটি ঠিক কাজ করা উচিত। যাইহোক, এই দ্বিতীয় সমাধানটিতে সুরক্ষা জড়িত রয়েছে।

Comments

আমি এর পরিবর্তে কোন আউটপুট পেতে Removed symlinkএবং পরে systemctl disable avahi-daemon.socketআগের মতোই ব্যর্থ হয়, একই লাইন উত্পাদকaudit.log

— spraff

আপনি কি সেলিনাক্স প্রয়োগকারী মোডটি অক্ষম করার চেষ্টা করতে পারেন? setenforce 0

— ইলুয়ান কেরেল-এমনকি

systemctl disable avahi-daemon.socketsetenforce 0ছাড়াই সফল হয় systemctl daemon-reexec(এবং আমি এখন বুঝতে পারি যে unmaskহুকুমটি আপনার নয়, আমার :-)) কেবল এটি করা এবং তার setenforce 1পরে কি ঠিক আছে ?

— 21

@ স্প্রেফ আমি জানি না, আমি সেলিনাক্স নবাগত হা হা। setenforce 0আমার উত্তরটিতে ইমাম উল্লেখ করেছেন ।

— ইলুয়ান কেরিয়েল-এমনকি

দয়া করে না setenforce 0। এটি উত্পাদন পরিবেশে একটি খারাপ অনুশীলন। systemctl daemon-reexecপরিবর্তে ব্যবহার করুন।

— ইউনুস

Answer 2

আমার ক্ষেত্রে, আমি সবেমাত্র আপগ্রেড করেছি systemdএবং যে কোনও systemctlআদেশ ব্যর্থ হয়েছিল:

# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied

তবে initম্যানপেজ অনুযায়ী , আপনি SIGTERMপিআইডি 1 হিসাবে চলমান ডিমনকে প্রেরণ করে একই কাজ করতে পারেন , যা কাজ করেছে:

kill -TERM 1

এটি ডেমনটি পুনরায় লোড করেছে, তারপরে সমস্ত systemctlকমান্ড আবার কাজ করা শুরু করে।

Comments

ধন্যবাদ। দীর্ঘদিন পরে একটি আর্চলিনাক্স ডিস্ট্রো আপগ্রেড করার পরে আমার সমস্যার সমাধান হয়েছে।

— বুয়েরি

উবুন্টু 18.10 এ কাজ করেছেন - ধন্যবাদ!

— রায় শিলকরটের

Answer 3

কোনও সমাধানই আমার পক্ষে কাজ করেনি। দেখা গেল যে আমার। সার্ভিস ফাইলে লাইনগুলির মধ্যে একটিতে একটি অনুপস্থিত = চিহ্ন রয়েছে। আমি এটি / var / লগ / বার্তাগুলি অনুসন্ধান করে আবিষ্কার করেছি এবং সেখানে একটি ত্রুটি দেখতে পেয়েছি যা আরও বর্ণনামূলক। সুতরাং অ্যাক্সেস অস্বীকৃত বিভ্রান্তিকর ছিল। এটি আসলেই কোনও সুরক্ষা সমস্যা ছিল না।

Comments

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

— রামহাউন্ড

কোন লগ ফাইল বার্তা দেখায়?

— রজারডপ্যাক 16'19