পথে নির্বাহযোগ্য, যার দ্বারা সন্ধানযোগ্য, তবুও পুরোপুরি যোগ্যতার পথ ছাড়া কার্যকর করা যায় না?


12

আমি একটি উদ্ভট সিম্পল শেল ইস্যু পেয়েছি, $ PATH- র একটি কমান্ড সহ যে শেলটি (ksh, লিনাক্সে চলমান) কাপুরুষোচিতভাবে প্রার্থনা করতে অস্বীকার করেছে। কমান্ডটি পুরোপুরি যোগ্যতা ছাড়াই পেলাম:

#  mycommand
/bin/ksh: mycommand: not found [No such file or directory]

তবে ফাইলটি এটি দ্বারা পাওয়া যাবে:

#  which mycommand
/home/me/mydir/admbin/mycommand

আমি সেই ডিরেক্টরিটি স্পষ্টভাবে $ PATH তেও দেখতে পাচ্ছি:

#  echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin

Location অবস্থানের এপিকে স্বাভাবিক বলে মনে হচ্ছে:

#  file /home/me/mydir/admbin/mycommand
/home/me/mydir/admbin/mycommand: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped

# ls -l mycommand  
-r-sr-s--- 1 me mygroup 97892 2012-04-11 18:01 mycommand

এবং যদি আমি এটি সম্পূর্ণরূপে যোগ্যতাসম্পন্ন পাথ ব্যবহার করে স্পষ্টভাবে চালিত করি:

#  /home/me/mydir/admbin/mycommand

আমি প্রত্যাশিত আউটপুট দেখতে পাচ্ছি। এখানে অবশ্যই শেলটি কিছুটা বিভ্রান্ত করছে, তবে আমি কী ক্ষতি হতে পারি?

সম্পাদনা: সাদৃশ্যযুক্ত প্রশ্নের মতো দেখতে কী সন্ধান করা: কোনও পথ দিয়ে চালানোর সময় বাইনারি কার্যকর হবে না। উদাহরণস্বরূপ> ./ প্রোগ্রামটি কাজ করবে না তবে> প্রোগ্রামটি ভাল কাজ করে

আমি আমার AT PATH তেও এরকম একাধিক কমান্ডের জন্য পরীক্ষা করেছি, তবে কেবল একটিই খুঁজে পেয়েছি:

# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand

EDIT2:

আজ সকালে হিসাবে, সমস্যাটি বিলুপ্ত হয়ে গেছে , এবং আমি এখন নির্বাহযোগ্যকে কার্যকর করতে সক্ষম হয়েছি।

এটি লগআউট এবং লগইন করার পরামর্শটিকে বৈধতা হিসাবে বিবেচনা করা যেতে পারে, তবে আমি গত রাতে সফলতা ছাড়াই এটি করেছি। সেই লগআউট / লগইনটিতে 'হ্যাশ-আর' কমান্ডটি চালিত করার সমতুল্য করা উচিত ছিল যা প্রস্তাবিত হয়েছিল (যা fww এছাড়াও একটি ksh বিল্টিন হিসাবে উপস্থিত হয়, এবং কেবল একটি বাশ বিল্টিন হিসাবে দেখা যায় না)।

কিছু উত্তরের জবাবে:

  • এটি একটি এক্সিকিউটেবল নয় স্ক্রিপ্ট (ফাইল কমান্ড আউটপুটে ELF রেফারেন্স দেখুন)।

  • আমি মনে করি না যে কোনও স্ট্রেস সাহায্য করেছিল। এটি সম্পূর্ণরূপে যোগ্যতাসম্পন্নকে কার্যকর করতে আদেশ জোর করে শেষ করে। আমি মনে করি যে আমি বর্তমান শেলটিতে স্ট্রেস সংযুক্তি করতে পারতাম, তবে যেহেতু আমি আর তিরস্কার করতে পারব না সে চেষ্টা করার কোনও মানে নেই।

  • $ PATH তে কোনও সেমিকোলন ছিল না। যেহেতু আমি আর তিরস্কার করতে পারি না, তাই আমি এই প্রশ্নটি পুরো $ PATH দিয়ে বিশৃঙ্খলা করব না।

  • অন্য শেলের চেষ্টা করা (অর্থাত্ বাশ) এমন কিছু হত যা আমিও চেষ্টা করতাম, যেমনটি পরামর্শ দেওয়া হয়েছিল। সমস্যাটি চলে যাওয়ার সাথে সাথে আমি জানি না যে এটি সাহায্য করত কিনা।

এটি আমার কাছে ডিরেক্টরি অনুমতিগুলি যাচাই করাও পরামর্শ দেওয়া হয়েছিল। এটি করার জন্য, প্রতিটি ডিরেক্টরি পর্যন্ত আমি এটি দেখতে পেলাম:

# ls -ld $HOME $HOME/mydir $HOME/mydir/admbin
drwxr-xr-x 10 me root    4096 2012-04-12 12:20 /home/me
drwxrwsr-t 22 me mygroup 4096 2012-04-12 12:04 /home/me/mydir
drwxr-sr-x  2 me mygroup 4096 2012-04-12 12:04 /home/me/mydir/admbin

OME হোম ডিরেক্টরি ডিরেক্টরি মালিকানা বিশৃঙ্খলাযুক্ত (মূল গোষ্ঠী হওয়া উচিত নয়)। এটি অন্যান্য সমস্যার কারণ হতে পারে, তবে আমি দেখতে পাচ্ছি না এটি কীভাবে এটির কারণ হতে পারে।


2
আপনার স্ক্রিপ্টিং কুং-ফু দুর্দান্ত।
জেফ ফেরল্যান্ড

2
আমি এই শব্দগুলি অত্যধিক সরল মনে করি তবে আমার একবার একই সমস্যা হয়েছিল এবং এটি কোলনের পরিবর্তে পথ বিভাজক হিসাবে ব্যবহৃত একটি অর্ধ-কোলন হিসাবে দেখা গেছে।
জন গার্ডেনিয়ার্স

আপনি কি আপনার পুরো पथপথটি সরবরাহ করতে পারেন?
জেসন হান্টলি

এটি একটি অসামান্য ভাল লেখা প্রশ্ন।
gWaldo

শেল এর ক্যাচিং হতে পারে?
মাইকেল স্লেড

উত্তর:


1

আপনার সম্ভবত আপনার $PATHব্যবহারের ক্ষেত্রে শেলের ক্যাশে আইটেমগুলি আপডেট করতে হবে hash -r


$ apropos hash | grep ksh- কিছুই না। আপনি একটি bashঅন্তর্নির্মিত উত্তর দিয়েছিলেন , কিন্তু এটি প্রশ্নে শেল নয়।
জেফ ফেরল্যান্ড

1

এছাড়াও, এই জাতীয় ক্ষেত্রে, প্রোগ্রামটি ডায়নামিক লিঙ্কারের কাছে আর্গুমেন্ট হিসাবে নির্বাহযোগ্যকে পাস করার মাধ্যমে ডাকা হয় তখন কী হয় তা পরীক্ষা করুন (কিছু সিস্টেমে setuid / setgid করার সময় তা করতে অস্বীকার করতে পারেন)।

ldd (1) উভয় ক্ষেত্রে আউটপুট এছাড়াও প্রকাশ হতে পারে। এক্সিকিউটেবল ফাইলটিতে "এই জাতীয় কোনও ফাইল বা ডিরেক্টরি নেই" এর অর্থ হ'ল এক্সিকিউটেবল ফাইলে নির্দিষ্ট করা ডায়নামিক লিঙ্কারটি খুঁজে পাওয়া যায় না (কল্পনা করুন এক্সিকিউটেবলের # এর ই এলফিন ফর্ম রয়েছে! / lib / ld-linux.what.so.ever ভিতরে)

এই আচরণের ফলে লোকেরা দুর্বল হয়ে পড়েছিল যেগুলি এখানে libc5 যুগের শেষের সাক্ষী ছিল, এবং এখন মাঝে মাঝে মিশ্র আই 386 / এএমডি 64 এর যুগে মানুষকে বুনোতে দুটি লাইব্রেরি সেটকে সমর্থন করার বিভিন্ন উপায়ে মূ .় করে তোলে।

এক্সিকিউটেবল বনাম $ পিডাব্লুডিতে আপেক্ষিক RPATH?

PS অন্য প্রশ্নটি ম্যাকোএসএক্স সম্পর্কিত, যা সম্ভবত ডিল্ড ব্যবহার করে এবং লিবিসি সরবরাহিত লিঙ্কারটি নয় not খুব ভিন্ন ধরণের প্রাণী।


0

ঠিক আছে, আমার কাছে কোনও উত্তর নেই। আমি কয়েকটি জিনিস প্রমাণ করেছিলাম এবং মনে করি এটির পরে আমি যুক্ত করতে পারি:

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

সুতরাং, সমস্ত অ্যাকাউন্টের দ্বারা, আমি এখনও বিভ্রান্ত কেবল গ্রিনগুলির জন্য এবং বন্ধ সুযোগটিতে এটি শেল-সম্পর্কিত বাগ, আপনি কি অন্য শেল দিয়ে চেষ্টা করতে পারেন?


0

আমি অনুমান করছি যে #! এর পরে আপনার স্ক্রিপ্টের কোনও বৈধ শেল নেই। উদাহরণস্বরূপ, কিছু পুরানো এসসিও সিস্টেমে #! / বিন / ব্যাশ সহ স্ক্রিপ্টগুলি কাজ করে না কারণ বাশ সত্যই / ইউএসআর / বিন / ব্যাশে থাকে। বোবা, তবে আরে এসসিও প্রায় এক কারণে মারা গেছে, না?

আপনার শেলটি পরীক্ষা করুন এবং নিশ্চিত করুন যে এটি একটি আসল বাইনারি / স্ক্রিপ্টের দিকে নির্দেশ করে।

সম্পাদনা করুন: এটি কোনও স্ক্রিপ্ট বা বাইনারি কিনা তা জানায় না, তবে আপনার 'এলএস-এল' আউটপুটটি সঠিক বলে ধরে নিচ্ছেন, তাহলে আপনার সম্ভবত সম্ভবত একটি 93kbyte স্ক্রিপ্ট নেই ... সুতরাং সম্ভবত এটি আমার উত্তর হ'ল বাইনারি অর্থ সম্পূর্ণ ভুল

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


এটি একটি এক্সিকিউটেবল ছিল এবং স্ক্রিপ্ট নয় (প্রশ্নের ফাইল থেকে ELF তথ্য দেখুন)) হ্যাঁ, আমি লগ আউট চাই এবং হবে।
Peeter Joot

0

আমার অনুমানগুলি:

  • আপনার একটি নাম ছিল mycommand। উদাহরণ স্বরূপ:

    alias mycommand=something
    
  • আপনি নামে একটি ফাংশন ছিল mycommand। উদাহরণ স্বরূপ:

    mycommand() { something; }
    

পরের বার আপনার যদি সমস্যা হয়, command -V mycommandশেলটি কী ধরণের কমান্ড বিশ্বাস করে তা দেখার জন্য দৌড়ে চেষ্টা করুন mycommand


এই দুটির কোনওটিই এই আদেশের ক্ষেত্রে ছিল না।
পিটার জুট

0

কোন উত্তর নেই, কেবল একগুচ্ছ চিন্তা:

  1. ফাইলের নামটিতে সাদা স্থান রয়েছে কিনা তা পরীক্ষা করুন; ট্যাব-সমাপ্তি এবং পরামিতি হিসাবে ব্যবহার করার সময় এটি নিঃশব্দে উপেক্ষা করে।
  2. ডিরেক্টরিতে অন্য স্ক্রিপ্ট / প্রোগ্রাম চেষ্টা করুন।
  3. স্ক্রিপ্টটি কার্যকর করার চেষ্টা করে শেলটি স্ট্রেস-ইন করার চেষ্টা করুন এবং দেখুন কোথায় এটি ব্রেক হয়েছে।

0

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

আমি যে লক্ষণগুলির মুখোমুখি হলাম সেগুলি নিম্নলিখিত ছিল। / আমার / হোম ডিরেক্টরিতে একটি স্ক্রিপ্ট (myscript.pl) রয়েছে। এখন এটি চালানোর চেষ্টা করছেন:

> /my/home/myscript.pl
myscript.pl:  permission denied.

ফাইলটির যাচাইকৃত অনুমতি (কার্যকর কার্যকর পতাকা সেট করা আছে)। যাচাই করা হয়েছে $ PATH (যদিও কোনও সমস্যা হওয়া উচিত নয়)।

তারপরে আমি চেষ্টা করব (যাচাই করার পরে স্ক্রিপ্টে নির্বাহী পতাকাটি সেট করা আছে):

> cd /my/home/
> ./myscript.pl:  permission denied.

হুমম ... সুতরাং সম্ভবত স্ক্রিপ্টটি সঠিক স্ক্রিপ্টিং ভাষা কল করছে না (এই ক্ষেত্রে পার্ল)। স্ক্রিপ্টের শীর্ষে সঠিক যাদু রয়েছে:

#!/usr/bin/perl

এবং প্রকৃতপক্ষে / usr / বিন / পার্ল বিদ্যমান এবং কাজ করে। সুতরাং নিম্নলিখিত কলটি সঠিকভাবে কাজ করে।

/usr/bin/perl myscript.pl

ট্যাব স্বতঃ-সম্পূর্ণ ফাইলটি প্রদর্শন করবে না (না কোনও হয় tcshনা bash)।

এটি আমাকে সত্যিই ফেলে দিয়েছে। তারপরে মনে পড়ে যে কয়েক মাস আগে আমার হার্ডডিস্কটি ক্র্যাশ হয়ে গেছে এবং আমার ল্যাবটিতে থাকা তরুণ সিস্টেম প্রশাসক সিস্টেমটি পুনরায় ইনস্টল করেছেন। ভেবেছিল সে পার্টিশনের অনুমতি নিয়েছে। এবং প্রকৃতপক্ষে, /etc/fstabকার্য সম্পাদনের অনুমতিটি অনুপস্থিত ছিল!

/dev/sda1    /my     /ext4      rw,user

পরিবর্তে

/dev/sda1    /my     /ext4      rw,user,exec

পরিবর্তন /etc/fstabএবং পুনঃনির্মাণের মাধ্যমে এটি স্থির করে :

mount -v -o remount /my

এটি সমস্যার সম্পূর্ণ সমাধান করেছে। আমার ধারণা হ'ল মূল পোস্টারের সমস্যার সাথে একই রকম ঘটনা ঘটতে পারে, কেবলমাত্র সেখানে অনুমতি সংক্রান্ত সমস্যাটি অন্তর্ভুক্ত ছিল (উদাহরণস্বরূপ, একটি অস্থায়ী পরিবর্তন হয়েছে যা সম্ভবত একটি রিবুট দিয়ে সমাধান করা যেতে পারে, যদি এটি ঘটে থাকে)।


-1

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

নেস্টেড স্ক্রিপ্টে কমান্ডের ঠিক আগে, আমি কমান্ডটি প্রিন্ট করেছিলাম, যেমন ইকো $ (যা মাইকম্যান্ড)

মাইকম্যান্ড: / হোম / আমি / বিন / মাইকম্যান্ড

তারপরে আমি এটি প্যারেন্ট স্ক্রিপ্ট থেকে চালানোর চেষ্টা করব:

/ হোম / আমি / বিন / কিছু_পরিচয়_স্ক্রিপ্ট []২]: মাইকম্যান্ড: পাওয়া যায় নি [এ জাতীয় কোনও ফাইল বা ডিরেক্টরি নেই]

প্রশ্নকারীর মতোই, আমি সমস্যার উত্স নির্ণয় করতে অক্ষম ছিলাম। আমার পথটি সঠিকভাবে দেখেছিল, এটি ছিল যা সক্ষম - এবং হ্যাশ মাইকম্যান্ডের কোনও পূর্ববর্তী প্রবেশগুলি প্রকাশ করেনি। পরের দিন যখন আমি লগ ইন করলাম, সবকিছু আবার যাদুতে আবার কাজ করেছিল। এখন, আমি এখানে নোট করব যে একটি মাউন্ট পুনঃস্থাপন করা হয়েছিল যেখানে এই সমস্যাটি দেখার আগে তার আগে একটি ज्ञিত সিস্টেম সমস্যা দেখা দিয়েছে। সম্ভবত এটি একটি সূত্র?

আমার যদি লগ ফাইলের পরে লগ ফাইল না দেখায় যে এটি ঘটেছিল তা প্রমাণ করে, আমি এটি সম্ভব হত বলে বিশ্বাস করব না! প্রশ্নকারীকে ধন্যবাদ, আমি আর পাগল বোধ করি না!

পিএস আমি মনে করি না যে ব্যবহারকারীর নাম 61১61১ as০ এ প্রতিবেদকের মতোই একই সমস্যা ছিল, তবে এটি সম্পর্কিত বলে মনে হয় এবং মাউন্ট তত্ত্বকে বিশ্বাসযোগ্যতা দেয়।

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