क्या कंप्यूटर के बीच फाइल ट्रांसफर करते समय फाइल का मालिकाना हक बदल जाता है?

Question

परिदृश्य: कंप्यूटर A ( userA ) के तहत बनाई गई फ़ाइल , जो फ़ाइल अनुमतियों में userA के रूप में फ़ाइल स्वामित्व लेती है , फिर एक अलग उपयोगकर्ता ( userB ) के साथ कंप्यूटर B में स्थानांतरित की जाती है ...।

Does the ownership of the original file change from the original user (userA) in computer A to the user (userB) of computer B?

How can I create a file that is only writable by me, the creator and owner, and only readable to anyone who might receive that file on other computers?

मैंने कंप्यूटर ए ( बी ) से पहले फाइल करने के बाद कंप्यूटर ए से लेकर बी तक ट्रांसफर करने की अनुमति देने के बाद कंप्यूटर ए ( यूजर ) पर फाइल परमिशन 755 के साथ एक टेस्टफाइल.टेक्स्ट बनाया था। मैंने देखा कि कैसे मेरी ओरिजनल फाइल अब कंप्यूटर बी पर है। , के रूप में उपयोगकर्ता आईडी है UserB बजाय USERA [जहां फ़ाइल बनाया गया था]।

कंप्यूटर A, 'userA' वाले

rwx-rxr-- userA testfile.txt

कंप्यूटर बी, 'userB' होने

rwx-rxr-- userB testfile.txt

मैंने सोचा था, और मालिक द्वारा फ़ाइल को केवल पठनीय, लिखने योग्य, और निष्पादन योग्य बनाने के लिए (जो मुझे लगा कि मैं जिस कंप्यूटर से फ़ाइल बनाता हूं, वह उपयोगकर्ता होगा)।

धन्यवाद! मैं इस पर नया हूँ!

Answer 1

हाँ।

यह सब इस बात पर निर्भर करता है कि गंतव्य पर फ़ाइल कौन बनाता है। इसे इस्तेमाल करे:

$ touch some_file
$ ls -l some_file
-rw-r--r-- 1 userA userA 0 Apr 9 17:44 some_file
$ ls -ln some_file
-rw-r--r-- 1 501 501 0 Apr 9 17:44 some_file

तो मेरे उदाहरण में, उपयोगकर्ता का संख्यात्मक यूआईडी 501 है।

अब इसे ट्रांसफर करें, रिमोट सिस्टम में यूजरबी के रूप में लॉग इन करें:

$ scp some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:50 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:50 some_file

जैसा कि आप यहाँ देखते हैं, userB ने फ़ाइल बनाई है, और userB के पास संख्यात्मक uid 1743 है। यह भी देखें कि टाइमस्टैम्प कैसे बदल गया?

यह scp का डिफ़ॉल्ट व्यवहार है। हालांकि आप scp के "-p" विकल्प का उपयोग करके विशेषताओं को संरक्षित कर सकते हैं। यह केवल टाइमस्टैम्प और अनुमतियों को संरक्षित करता है - और महत्वपूर्ण बात, स्वामित्व नहीं। यह वही हो सकता है जो आप देख रहे हैं:

$ scp -p some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:44 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:44 some_file

ध्यान दें कि scp के अलावा, दूरस्थ मशीनों पर फ़ाइलें बनाने के कई अलग-अलग तरीके हैं - NFS, FTP, WebDAV ... ये अलग-अलग, लेकिन समान रूप से पूर्वानुमानित तरीके से व्यवहार करेंगे। चलो हालांकि दूर नहीं किया जाता है - आपने एससीपी के बारे में पूछा।

(OT नोट, आपने वास्तव में 754 अनुमतियों के साथ फाइल बनाई है! Rwx = 111 = 7, rx = 101 = 5, r - = 100 = 4 - आप देखते हैं, r, w और x एक अष्टक शब्द में बिट हैं जहाँ r = 4, w = 2, x = 1। यही कारण है कि आप अनुमतियों के संबंध में अष्टक के संदर्भ देखेंगे। सुधार के लिए धन्यवाद ernie!)

Comments

महान! तो फाइलों पर अनुमति, विशेष रूप से 'स्वामी' की अनुमति, मूल रूप से एक ही प्रणाली के तहत फाइलों के प्रबंधन के लिए अधिक हैं (विभिन्न उपयोगकर्ता खातों के साथ)? चूँकि किसी अन्य कंप्यूटर सिस्टम में स्थानांतरित किया गया कोई भी फ़ाइल सिस्टम के साथ उस फ़ाइल के स्वामित्व को ओवरराइड कर देगा .... सही? यदि हां, तो क्या किसी फ़ाइल के स्वामित्व को बनाए रखने का एक तरीका है जिसे आप उन प्रणालियों के आसपास स्थानांतरित कर सकते हैं जो स्वामी की पहुंच प्राप्त नहीं कर सकते हैं? -धन्यवाद!

— ब्रेटोनीक्स

अंत में वे अनुमतियाँ (जैसे 111) अष्टाधारी नहीं हैं, वे द्विआधारी हैं। 7, 5, और 4 को अष्टक माना जा सकता है (या अधिक आधार वाली कोई संख्या प्रणाली), हालांकि मुझे लगता है कि आप दशमलव समकक्षों को व्यक्त करने की कोशिश कर रहे थे।

— इर्नी

@ macam ऐसा लगता है जैसे आप एक ऐसी फ़ाइल बनाने के लिए कह रहे हैं जो केवल-हर जगह पढ़ी जाती है। यह वास्तव में संभव नहीं है, जब तक आप फ़ाइल नहीं लिखते हैं, तब अनुमतियाँ बदलें। यदि कोई उपयोगकर्ता डिस्क पर फ़ाइल लिखने में सक्षम था, तो वे इसे संपादित करने में सक्षम होने जा रहे हैं। ध्यान दें कि कुछ फ़ाइल स्वरूप आपको फ़ाइलों के केवल-पढ़ने वाले संस्करण बनाने की अनुमति देते हैं, लेकिन इसका मतलब है कि केवल उनके टूल के भीतर रीड-ओनली (पीडीएफ इसका एक अच्छा उदाहरण है)। आप अभी भी अंतर्निहित 0s और 1s को सीधे संशोधित कर सकते हैं।

— इर्नी

सही ओर्नी, मैं अष्टक सोच रहा था, बाइनरी लिखना ... क्या एक मूर्खतापूर्ण गलती है! मैं इसे अपडेट करूंगा ताकि यह तथ्यात्मक रूप से गलत न हो।

— रिच

Answer 2

जब आप दूरस्थ रूप से स्थानीय रूप से कॉपी कर रहे हों तो scp का सामान्य रूप है:

scp localfile username@remotehost:/some/remote/directory

इस स्थिति में, आप बता रहे हैं कि आप usernameरिमोट सिस्टम पर लॉग इन करना चाहते हैं , और यह है कि उपयोगकर्ता नाम के साथ लिखा जाएगा। आपके उदाहरण में सबसे अधिक संभावना है, आपने उस उपयोगकर्ता का उपयोग किया था जब आप फ़ाइल को कंप्यूटर बी में भेज रहे थे।

यदि आप किसी दूरस्थ फ़ाइल को किसी लोकलहोस्ट को कॉपी कर रहे हैं, जैसे:

scp username@remotehost:/some/remote/file /some/local/directory

इस स्थिति में, आप usernameदूरस्थ सिस्टम के रूप में लॉगिन करते हैं , और फिर इसे स्थानीय रूप से उस उपयोगकर्ता के रूप में लिखते हैं, जैसे आप scp कमांड चला रहे हैं। यह उदाहरण आपके द्वारा चलाए जा रहे सिस्टम के लिए दूरस्थ होस्ट से फ़ाइल की प्रतिलिपि बना देगा, जैसा कि आप वर्तमान में लॉग इन किए गए उपयोगकर्ता के रूप में करते हैं (क्योंकि लेखन वर्तमान में उपयोगकर्ता द्वारा लॉग इन किया जाएगा)। यह रिमोटहोस्ट पर कुछ भी प्रभावित नहीं करेगा, क्योंकि आप केवल वहां से फाइल पढ़ रहे हैं, और इसे स्थानीयहोस्ट पर कॉपी कर रहे हैं। चूंकि आप दूरस्थ फ़ाइल को पढ़ने में सक्षम हैं, इसलिए स्थानीय फ़ाइल में आपके लिए लिखने की अनुमति है, क्योंकि आप फ़ाइल को स्थानीय रूप से लिख रहे हैं।

दूसरा तरीका रखो - फ़ाइल का मालिक आम तौर पर फ़ाइल के लेखक से मेल खाएगा। इसलिए, यदि आप userA के रूप में लॉग इन हैं, और एक फाइल लिखते हैं, तो मालिक userA होगा। एक सरल उदाहरण कुछ इस तरह हो सकता है:

user@server:~$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 6615 Apr  9 17:09 /var/log/syslog  

ध्यान दें कि यह फ़ाइल syslog के स्वामित्व में है, लेकिन यह किसी के द्वारा स्वीकार्य समूह में पढ़ने योग्य है, जो उपयोगकर्ता के अंतर्गत आता है। तब यदि हम फ़ाइल को उपयोगकर्ता की होम डायरेक्टरी (~ /) में कॉपी करते हैं:

user@server:~$ cp /var/log/syslog ~/
user@server:~$ ls -l ./syslog
-rw-r----- 1 user user 6615 Apr  9 17:10 ./syslog

ध्यान दें कि फ़ाइल का कॉपी किया गया संस्करण अब स्वामित्व में है user। scpएक ही काम कर रहा है, स्रोत या गंतव्य को छोड़कर एक अलग उपयोगकर्ता के रूप में लॉगिंग को एक अलग सिस्टम में शामिल कर सकता है।

ध्यान दें कि अनुमतियों को उपयोगकर्ता आईडी, उपयोगकर्ता के एक संख्यात्मक पुन: संयोजन के साथ ट्रैक किया जाता है। आप अपने वर्तमान यूआईडी को idकमांड के साथ देख सकते हैं । सामान्य तौर पर, व्यक्तिगत प्रणालियों के लिए, यूआईडी सिस्टम के लिए एक ही प्रणाली नहीं होगी क्योंकि खाते साझा नहीं किए जाते हैं (जब तक कि आप एलडीएपी या समान का उपयोग नहीं कर रहे हैं)। मेरा मानना ​​है कि परंपरागत रूप से, 0 रूट है, 1000 से कम यूआईडी सिस्टम खातों (जैसे मेल, समाचार, बिन, डेमन, आदि) के लिए आरक्षित हैं, और यह कि नियमित उपयोगकर्ता 1000 से शुरू होते हैं। जहां तक ​​मुझे पता है, नियमित उपयोगकर्ता यूआईडी असाइन किए गए हैं क्रमिक रूप से, इसलिए यदि आपने तीन खाते बनाए हैं, तो वे संभवतः 1000, 1001 और 1002 होंगे।

रीड-ओनली फ़ाइल भेजने के अपने मूल प्रश्न पर वापस, आपको यह सुनिश्चित करना होगा कि दूरस्थ सिस्टम पर पाठक के पास फ़ाइल के मालिक के समान यूआईडी नहीं है। यदि आप (userA) userB के लिए एक फाइल तैयार कर रहे थे, तो आप कुछ ऐसा कर सकते थे:

scp localfile userA@remotehost:/some/remote/directory

इस स्थिति में, फ़ाइल का मालिक समाप्त हो जाएगा userA, (और हम जानते हैं कि userA रिमोट सिस्टम पर मौजूद है क्योंकि हम इसमें लॉग इन हैं), और userB ने लिखने की अनुमति नहीं दी होगी (फ़ाइल को मूल रूप से 755 मान लिया गया था )। संपादित करें: आपको अनुमतियों को संरक्षित करने के लिए -p की आवश्यकता हो सकती है?

बेशक, यदि उपयोगकर्ता के पास रूट या sudo अनुमतियां हैं, तो वे फ़ाइल को लिखने योग्य बनाने में सक्षम होंगे, चाहे आप कुछ भी करें।

Comments

इसलिए मैंने दूसरे कोड "रिमोट यूजरनेम @ रिमोटहॉस्ट: / कुछ / रिमोट / फाइल / कुछ / लोकल / डाइरेक्टरी" को रिमोट सिस्टम (यूजरबी) के यूजरनेम के रूप में लॉगिन किया और फाइल को स्थानीय सिस्टम से यूजरए के रूप में लिखा। हालाँकि, कंप्यूटर पर फ़ाइल के मालिक की जाँच करने पर, फ़ाइल में फिर से 'userB' का मालिक होता है। आपने उल्लेख किया है कि आईडी को एक संख्यात्मक प्रतिनिधित्व के साथ ट्रैक किया जाता है और यह कि यूआईडीएस सिस्टम के लिए समान प्रणाली नहीं होगी क्योंकि खाते साझा नहीं किए जाते हैं, लेकिन दोनों सिस्टम के लिए मेरे दोनों यूआईडी एक ही यूआईडी # हैं, सोचा उपयोगकर्ता कंप्यूटर पर मौजूद नहीं है ? क्या इसीलिए फ़ाइल का स्वामित्व हस्तांतरित किया जाता है?

— 23

इसके अलावा, क्या विभिन्न कंप्यूटरों के सभी उपयोगकर्ता नाम समान UID # हैं? मैंने 3 मैक का परीक्षण किया, सभी में एक ही यूआईडी # था, एक भी जो मेरा नहीं था।

— भाइयों

मैंने उत्तर को संपादित किया - लघु संस्करण यह है कि एससीपी का दूसरा संस्करण फ़ाइल के दूरस्थ संस्करण को प्रभावित नहीं करेगा - यह केवल इसे पढ़ता है, और फिर स्थानीय रूप से फ़ाइल को लिखता है, जैसा कि उपयोगकर्ता स्कैप कमांड चला रहा है। यूआईडी को आमतौर पर क्रमिक रूप से सौंपा गया है, जो कि उपयोगकर्ता 1000 से शुरू होता है।

— ernie

Answer 3

जब आप फ़ाइल को स्रोत से गंतव्य तक स्थानांतरित करते हैं, तो अनुमतियाँ और वास्तव में स्वामित्व हस्तांतरण के मापदंडों के अधीन होते हैं। जैसा कि @ernie ने कहा, स्वामित्व इस बात पर निर्भर करता है कि आप फ़ाइल को कैसे स्थानांतरित करते हैं।

अनुमतियाँ umaskफ़ाइल पर निर्भर करती हैं ।

पुराने-स्कूल एफ़टीपी सर्वर के लिए, ऑमस्क आमतौर पर एफ़टीपी सर्वर कॉन्फ़िगरेशन में सेट किया जाता है। SFTP सर्वर (SSH, या scp पर cp) के लिए, आपको सर्वर गलती पर इस जवाब के अनुसार ssh के लिए PAM प्लगइन्स सेट करना होगा ।

Comments

तो scp के माध्यम से स्थानांतरण स्वामित्व? आप किसी फ़ाइल को उनके यूआईडी में फ़ाइल के स्वामित्व को बदलने के बिना कैसे भेज सकते हैं?

— ब्रेटनिक्स 23