GPG S.gpg-एजेंट से कनेक्ट नहीं कर: कनेक्शन अस्वीकृत

वोट
0

मैं GPG एजेंट का उपयोग इसलिए मैं अपने फ़ाइल एन्क्रिप्शन प्रक्रिया को स्वचालित कर सकते हैं GPG पूर्व निर्धारित पदबंध कैशिंग सेट करने का प्रयास कर रहा हूँ। GPG-एजेंट के लिए आदेश चलाने के लिए और ठीक से पदबंध को कैश करने के अलावा, यह वहाँ एक होने की जरूरत है लगता है S.gpg-एजेंट ~ / .gnupg / निर्देशिका है कि रूट निर्देशिका में उत्पन्न हो जाता है जब मैं GPG की स्थापना की और भीतर स्थित सॉकेट GPG-एजेंट।

क्या मैंने किया है (और जो अतीत में काम करने के लिए लग रहा था) मैं रूट के रूप में सब कुछ शुरू करने और सॉकेट और उपयोगकर्ता के लिए निर्देशिका के लिए अपने कम विशेषाधिकार प्राप्त उपयोगकर्ता और प्रदान करने की अनुमतियों को /.gnupg निर्देशिका की सामग्री पर कॉपी होता है। आदेशों मैं भाग गया GPG-एजेंट डेमॉन और कैश पदबंध शुरू करने:

gpg-agent --homedir /home/<user>/.gnupg --daemon
/usr/libexec/gpg-preset-passphrase --preset --passphrase <passphrase> <keygrip>

GPG-एजेंट प्रक्रिया ठीक चल रहा प्रतीत हो रहा है, लेकिन मैं दूसरी पंक्ति से त्रुटि नीचे मिलती है:

gpg-preset-passphrase: can't connect to `/home/<user>/.gnupg/S.gpg-agent': Connection refused
gpg-preset-passphrase: caching passphrase failed: Input/output error

मुझे यकीन है कि सॉकेट उचित अनुमति के साथ निर्देशिका में मौजूद है और इस प्रक्रिया को रूट के रूप में चलाता है बना दिया है। ऐसा लगता है कि इस सॉकेट अभी भी स्वाभाविक जड़ भले ही मैं कॉपी और संशोधित अनुमतियों से जुड़ा हुआ है। तो मेरी सवाल कर रहे हैं

  1. वास्तव में किस प्रकार इस सॉकेट प्रारंभ होता है?
  2. वहाँ किसी अन्य उपयोगकर्ता के रूप में मैन्युअल रूप से करने के लिए एक तरीका है?
03/12/2019 को 00:00
का स्रोत उपयोगकर्ता
अन्य भाषाओं में...                            


1 जवाब

वोट
0

यह पता चला मुद्दे से संबंधित नहीं था gpg-agentऔर gpg-preset-passprhase

ध्यान दें: यह है नहीं एक स्थायी समाधान है, लेकिन यह मुझे इस मुद्दे को मैं का सामना करना पड़ रहा था पिछले पाने के लिए अनुमति दे दी।

संशोधित करने के बाद /etc/selinux/configऔर एसई लिनक्स अक्षम करने, मैं अब अनुभवी अनुमतियाँ ऊपर जारी करते हैं। एसई लिनक्स रेड हैट (मैं वर्तमान में RHEL7 पर इस चला रहा हूँ) द्वारा विकसित एक लिनक्स कर्नेल सुरक्षा मॉड्यूल है। ऐसा लगता है अगले कदम की संभावना का उपयोग कर मेरे उपयोगकर्ता से यकीन है कि इन बाईनरीस और संकुल अनुमति दी जाती है पहुँच बनाने के लिए किया जाएगा audit2allow। यह यहाँ पर थोड़ा और अधिक जानकारी: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow

05/12/2019 को 17:56
का स्रोत उपयोगकर्ता

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more