डेवलपर्स को अपने पीसी पर प्रशासक की अनुमति होनी चाहिए

135

क्या डेवलपर्स के पास अपने पीसी पर प्रशासक की अनुमति होनी चाहिए या उन्हें पावर यूजर एक्सेस पर्याप्त दे रही है?

कुछ टिप्पणियां:

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

हम 5 डेवलपर्स की टीम हैं और वेब एप्लिकेशन का निर्माण करते हैं

development-environment

116

अगर मैं नौकरी पर चला गया और मुझे अपनी मशीन पर कोई अधिकार नहीं मिला, तो मैं अगले दिन वापस नहीं आऊंगा। अपने डेवलपर्स को आसान बनाएं, कठिन नहीं।

— अन्नकूट

29

यह प्रश्न चयन पूर्वाग्रह से ग्रस्त है - ऐसे समय होते हैं जब डेवलपर की मशीनों को बंद कर दिया जाना चाहिए, लेकिन इस तरह की प्रतिक्रिया कभी भी डेवलपर्स के लिए तैयार साइट पर मतदान नहीं होगी।

— रोमनदास

5

एक से कम आम सोच सकते हैं। ज्यादातर मामलों में अंतर्निहित मुद्दा संवेदनशील डेटा है - उदाहरण के लिए, स्विस बैंकिंग गोपनीयता कानून डेवलपर्स को वास्तविक ग्राहक डेटा देखने से रोकते हैं (खाते का मिलान पाठक के लिए एक अभ्यास के रूप में छोड़ दिया जाता है)। इस मामले में समस्या मशीनों को बंद नहीं कर रही है बल्कि विकास कार्यों के लिए स्वच्छता डेटा सेट प्रदान कर रही है। अधिकांश अन्य स्थितियां या तो विनियामक आवश्यकताएं हैं (उदाहरण के लिए वर्गीकृत डेटा के साथ काम करना) या स्वयं सेवा CYA।

— ConcernedOfTunbridgeWells

12

मुझे आश्चर्य है कि ServerFault पर एक ही सवाल कैसे सामने आएगा ... (@romandas)

— बेन

4

@BenMosher: यहाँ आपका जवाब है: serverfault.com/questions/232416/…

— kmote

228

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

यह ध्यान में रखते हुए कि विकास कर्मचारियों के पास उत्पादन प्रणालियों के लिए आवश्यक रूप से रूट एक्सेस नहीं है, एक स्थानीय पीसी पर व्यवस्थापक अधिकार उत्पादन प्रणालियों की सुरक्षा से महत्वपूर्ण रूप से समझौता नहीं करते हैं। कर्मचारियों के लिए स्थानीय पीसी तक व्यवस्थापक पहुंच को प्रतिबंधित करने के लिए लगभग कोई वैध परिचालन कारण नहीं है जो इसे अपना काम करने की आवश्यकता है।

हालाँकि, प्रशासनिक पहुँच प्रदान करने का सबसे महत्वपूर्ण कारण यह है कि एक समझौता या दूसरी दर के विकास का वातावरण स्थापित करना आपके विकास कर्मचारियों को एक संदेश भेजता है:

'हम आपके काम को इतना कम महत्व देते हैं कि हम आपके काम को बिना किसी अच्छे कारण के करने की क्षमता से समझौता करने के लिए तैयार हैं। वास्तव में, हम अपने स्वयं के गधे को कवर करने के लिए ऐसा करने के लिए काफी खुश हैं, क्षुद्र नौकरशाही की सनक को भटकना या क्योंकि हम बस परेशान नहीं हो सकते हैं। यह सिर्फ सबसे अच्छा मामला है। सबसे बुरी स्थिति यह है कि हम वास्तव में इस प्रकार के नियंत्रण शैतान हैं जो इसे हमारे कार्य के रूप में देखते हैं कि आपको यह बताना है कि आप अपना काम कैसे करते हैं और आपको क्या करना है या करने की आवश्यकता नहीं है। आपको जो दिया गया है उसके साथ करें और आभारी रहें कि आपको नौकरी मिल गई है। '

आम तौर पर, विकास कर्मचारियों के लिए दूसरी दर (अकेले मौलिक रूप से त्रुटिपूर्ण) कार्य वातावरण प्रदान करना, अपने कर्मचारियों को पेशाब करने के प्राकृतिक परिणामों के लिए एक नुस्खा है - सक्षम लोगों, उच्च कर्मचारियों के कारोबार, खराब मनोबल और खराब गुणवत्ता के वितरण को बनाए रखने में असमर्थता। ऐसा करने के लिए अपने रास्ते से बाहर जा रहे हैं - विशेष रूप से अगर वहाँ नौकरशाही फुसफुसाते हुए का एक ओवरटोन है - बस गैर जिम्मेदाराना है।

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

एक ध्यान देने वाली बात यह है कि प्रशासनिक विशेषाधिकार यूनिक्स-ओआईडी या मेनफ्रेम सिस्टम की तुलना में विकास के मुद्दे पर कम हैं, क्योंकि यह विंडोज पर है। इन प्लेटफार्मों पर एक उपयोगकर्ता सिस्टम-वाइड अनुमतियों की आवश्यकता के बिना अपने स्वयं के डोमेन में कहीं अधिक कर सकता है। आप शायद अभी भी डेवलपर्स के लिए रूट या sudo एक्सेस चाहते हैं, लेकिन ऐसा नहीं होने से यह अक्सर कम हो जाएगा। यह लचीलापन कंप्यूटर विज्ञान स्कूलों में यूनिक्स-व्युत्पन्न ऑपरेटिंग सिस्टम की निरंतर लोकप्रियता का एक महत्वपूर्ण लेकिन कम ज्ञात कारण है।

— ConcernedOfTunbridgeWells
स्रोत

3

व्यवस्थापक अधिकार होने और व्यवस्थापक अधिकारों के साथ सब कुछ चलाने के साथ अंतर है :) कई डेवलपर्स को निश्चित रूप से व्यवस्थापक अधिकारों की आवश्यकता होगी। लेकिन एक स्थानीय प्रणाली पर व्यवस्थापक अधिकारों के साथ अंतःक्रियात्मक रूप से सब कुछ चलाना कम से कम विशेषाधिकार नहीं है। यह उत्पादन प्रणालियों के खिलाफ हमलों के लिए खुलता है जो डेवलपर के पास पहुंचता है और एक समझौता स्थानीय पीसी किसी भी हमलावर को समान पहुंच देता है। यह आपके विचार से आसान है। सुरक्षा एक परत-दर-परत समस्या है, प्रति प्रक्रिया कम से कम विशेषाधिकार और उपयोगकर्ता प्रशिक्षण मुद्दा। प्रत्येक उपकरण की सुरक्षा का सम्मान करना एकमात्र तरीका है: vimeo.com/155683357

— Oskar Duveborn

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

— L_7337

87

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

इसके अलावा, देव अक्सर डाउनलोड करते हैं और नई चीजों की कोशिश करते हैं। नेटवर्क व्यवस्थापक की आवश्यकता के अतिरिक्त चरणों को जोड़ना और उनके लिए कुछ स्थापित करना बस देव को निराश करता है और जल्दी से नेटवर्क ऑप्स व्यक्ति के लिए जीवन नरक बना देगा।

कहा कि, उन्हें THEIR बॉक्स पर एक व्यवस्थापक होना चाहिए, नेटवर्क नहीं।

— मैं नहीं
स्रोत

5

व्यवस्थापक अनुमतियों के साथ देवों के साथ मैंने जो सबसे बड़ी समस्या रखी है, वह यह है कि आप अपने स्थानीय कंप्यूटर संसाधनों पर अधिकार प्राप्त कर लेते हैं। इतना भद्दा सॉफ्टवेयर परिणाम - C: \ Program Files को लिखता है, HKLM को लिखता है, आदि, अपने वर्कस्टेशन पर, हो सकता है, लेकिन परीक्षण की आवश्यकता होती है कि आप कहाँ नहीं हैं।

— SqlRyan

4

@rwmnau: यह वेब विकास पर लागू नहीं होता है। सामान्य अनुमतियों के तहत QA'ing होने पर भी, समस्या बहुत जल्दी स्पष्ट हो जाती है।

— NotMe

2

VM को बिना व्यवस्थापक विशेषाधिकार के उपलब्ध कराना और देव-परीक्षण लॉगिन करना, परीक्षण की सुविधा के लिए एक अच्छा तरीका है कि सॉफ्टवेयर सामान्य उपयोगकर्ता अनुमतियों के साथ चलेगा।

— कंसर्नडऑफटुनब्रिजवेल्स

ऐसे एडमिन-ओनली परमिशन के साथ जारी किया जाने वाला सॉफ्टवेयर बेहद खराब (या कोई नहीं) क्यूए प्रक्रिया से गुजरा। सॉफ़्टवेयर को वास्तविक जीवन के वातावरण में परीक्षण किया जाना चाहिए, इसलिए क्यूए को इसे जल्दी से पकड़ना चाहिए और समस्या अन्यथा देवों द्वारा अनदेखी की जाएगी। सही?

2

@rwmnau - उनके नमक के लायक कोई भी डेवलपर इस बात से पूरी तरह वाकिफ है, लेकिन इसका जवाब उनकी देव मशीन को बंद करना नहीं है। यह उन्हें एक परीक्षण वातावरण प्रदान करने के लिए है कि वे इन मुद्दों को हल करने के लिए अपनी परियोजना को अपनी सुविधानुसार तैनात कर सकते हैं।

— स्पेंसर रूपोर्ट

48

हां और ना।

हाँ, यह सिस्टम के समर्थन में बहुत समय बचाता है।

नहीं, आपके उपयोगकर्ताओं के पास ऐसा नहीं है इसलिए इस पर भरोसा न करें।

हम बिना व्यवस्थापक अनुमति और परीक्षण के साथ विकसित होते हैं। जो सही काम करता है।

— तून Krijthe
स्रोत

11

मेरी पत्नी को अपने कंप्यूटर पर एक गैर-व्यवस्थापक खाते के लिए बहस करना था, इसलिए वह यह सुनिश्चित कर सकती थी कि उपयोगकर्ता वह कर सकते हैं जो वह कर सकती थी। आपकी नीति बिलकुल सही है (और इसलिए अपवित्र)।

— डेविड थॉर्नले

1

वास्तव में, देव के पास व्यवस्थापक, परीक्षण और QA उपयोगकर्ता होना चाहिए।

— डॉ। वाटसन

मैं आपके साथ अधिक सहमत नहीं हो सकता! व्यवस्थापक पहुंच विकसित करने के लिए बहुत अच्छा है, लेकिन अधिकांश उपयोगकर्ताओं के पास यह नहीं होगा (यदि आप कॉर्पोरेट सॉफ़्टवेयर विकसित करते हैं ... आईटी लॉक सामान आमतौर पर बहुत अच्छा होता है)।

— पुलसिहेड

18

स्थानीय प्रशासन हाँ, उपरोक्त सभी कारणों के लिए। नेटवर्क व्यवस्थापक नहीं, क्योंकि वे अनिवार्य रूप से नेटवर्क प्रशासन कार्यों में खींचे जाएंगे क्योंकि "वे कर सकते हैं"। देवों का विकास होना चाहिए। नेटवर्क प्रशासन एक पूरी तरह से अलग काम है।

— निक वान ब्रंट
स्रोत

15

डेवलपर्स को आमतौर पर उन चीजों को करने की आवश्यकता होती है जो औसत व्यक्ति नहीं करेगा, और इसलिए सामान्य रूप से व्यवस्थापक खाते होने चाहिए। अजीब हुप्स के माध्यम से उन्हें आशा करना उनका समय बर्बाद करता है और उन्हें ध्वस्त कर देता है। उच्च-सुरक्षा स्थितियों में अपवाद हो सकते हैं, लेकिन अगर आप किसी ऐसे व्‍यक्ति पर भरोसा नहीं कर सकते हैं, जिसके बारे में आपको यकीन है कि उनके कोड पर भरोसा नहीं किया जा सकता है।

उनके पास अपने उपयोगकर्ताओं के समान अनुमति का एक उपलब्ध खाता होना चाहिए (यदि उपयोगकर्ता के पूल के पास अलग-अलग अनुमति की स्थिति है तो एक से अधिक खाते हैं)। अन्यथा, वे बस कुछ अच्छा विकसित कर सकते हैं, इसे तैनात कर सकते हैं, और फिर यह पाते हैं कि यह उपयोगकर्ताओं के लिए काम नहीं करेगा।

व्यवस्थापक खातों के साथ कंप्यूटर को स्क्रू करने के भी कई तरीके हैं (हाँ, मैंने इसे किया है)। आईटी विभाग को एक नीति की आवश्यकता है कि वे एक डेवलपर के कंप्यूटर को फिर से छवि देंगे यदि वे इसे जल्दी से ठीक नहीं कर सकते हैं। एक स्थान पर मैंने अनुबंध किया, मुझे अपना व्यवस्थापक खाता प्राप्त करने के लिए उस नीति की एक प्रति पर हस्ताक्षर करना था।

यह एक सुंदर विंडोज-विशिष्ट उत्तर है। लिनक्स और अन्य यूनिक्स-वाई सिस्टम में, डेवलपर्स अक्सर उपयोगकर्ता खातों के साथ ही प्राप्त कर सकते हैं, अक्सर परीक्षण के लिए किसी अन्य खाते की आवश्यकता नहीं होती है (यदि उन्हें एक खाता मिला है जिसके साथ वे sudo कर सकते हैं, तो वे जानते हैं कि वे कब उपयोग कर रहे हैं सूडो, लेकिन उन्हें एक ही समूह की अनुमति के साथ एक की आवश्यकता हो सकती है), और ओएस को बहुत आसानी से अविश्वसनीय रूप से नुकसान पहुंचा सकता है, इसलिए समान आईटी नीति आवश्यक है।

— डेविड थॉर्नले
स्रोत

4

"उच्च-सुरक्षा स्थितियों में कुछ अपवाद हो सकते हैं, लेकिन यदि आप किसी ऐसे व्यक्ति पर भरोसा नहीं कर सकते हैं, जिसमें कोई व्यवस्थापक खाता है, तो आप उनके कोड पर भरोसा नहीं कर सकते।" - यह एक महान विचार है, धन्यवाद!

— उपयोगकर्ता

आप किसी भी तरह से कोड पर भरोसा नहीं कर सकते हैं: आपको हर चीज के लिए सहकर्मी की समीक्षा की जानी चाहिए। और मुझे लगता है कि इंस्टॉलेशन के लिए भी यह समझ में आता है: किसी ऐसे व्यक्ति को "सहकर्मी की समीक्षा" करने के लिए प्राप्त करें जो सॉफ्टवेयर वे स्थापित करने वाले हैं।

— टिम

10

हां, हाफ-लाइफ 1 (और सभी संबंधित मोड: काउंटर-स्ट्राइक, हार का दिन, आदि) विंडोज एनटी, 2000, एक्सपी, आदि में ठीक से काम करने के लिए प्रशासक के अधिकारों (कम से कम 1 रन के लिए, मुझे लगता है) की आवश्यकता है। ।

और, दोपहर के भोजन के समय काउंटर स्ट्राइक को किस तरह के डेवलपर नहीं खेलते हैं? (निश्चित रूप से एक भद्दा)

— fortran
स्रोत

10

मशीन पर व्यवस्थापक अधिकार के बिना विकसित होने के दर्द को सहन करने के बाद मेरा जवाब केवल हां हो सकता है, यह आवश्यक है।

— जेसन
स्रोत

8

पूर्ण रूप से! मैं रात में फिल्में डाउनलोड करने के लिए डाउनलोड प्रबंधक कैसे स्थापित करूंगा?

कभी-कभी डेवलपर्स को कुछ विचार का परीक्षण करने के लिए सिस्टम में चीजों को स्थापित करने या कुछ बदलने की आवश्यकता होती है। अगर आपको हर बार किसी चीज को बदलने की जरूरत है तो यह असंभव है कि आप एडमिन को बुलाएं।

मेरे पास मेरा व्यक्तिगत अवलोकन भी है कि कुछ व्यवस्थापक सभी को तंग करने के लिए तंग करते हैं जो कि छोटी चीज़ों को दैनिक आधार पर उन पर निर्भर करने के लिए संभव है ... इस प्रकार, क्या, उनकी नौकरी हासिल करना? अन्य उपयोगकर्ताओं से पेशाब करना? कोई उत्तर नहीं है। लेकिन सामान्य ज्ञान यहां नहीं देखा जाता है।

पिछली बार मेरे पीसी के साथ एक समस्या थी, मैंने सिस्टम को पुनर्स्थापित करने में एक सक्रिय भाग लिया, कुछ सुझाव जो कि टीम के साथ काम कर रहे थे, या तो मुझे लगा कि ... व्यवस्थापक ने बहुत गुस्सा किया और मुझ पर सिखाने का प्रयास करने का आरोप लगाया उसे या नियमों को फिर से परिभाषित करें। मुझे लगता है कि यह सिर्फ उसका अहंकार था क्योंकि वह अन्य सहयोगियों के बीच हमारे कमरे में उस शांत नहीं देखा गया था।

— उपयोगकर्ता
स्रोत

मैं और अधिक सहमत नहीं हो सकता। 6 साल के लिए सिस्टम एनजाइना होने के बाद कुछ तय करने के लिए हेल्पडेस्क पर कॉल करना दर्दनाक होता है।

— मैथ्यू व्हॉट्स

8

जवाब है, डेवलपर्स के पास 2 मशीनें होनी चाहिए !!

एक ऐसा विकास जिसमें व्यवस्थापक अधिकार और पर्याप्त शक्ति, मेमोरी, स्क्रीन आकार और पोर्टेबिलिटी, और ADMIN विशेषाधिकार हैं, कॉर्पोरेट एंटीवायरस सॉफ़्टवेयर लोड किए गए लेकिन डेवलपर द्वारा ऑटोरेसेट पॉलिसी के साथ आवश्यक होने पर कॉन्फ़िगर किए गए ..
एक कॉर्पोरेट कॉरपोरेट लोड, नीतियों, गैर-व्यवस्थापक उपयोगकर्ता विशेषाधिकारों, आदि ... डेवलपर इकाई परीक्षण रिलीज मोड अनुप्रयोगों के लिए इस एक का उपयोग कर सकते हैं क्योंकि कुछ डेवलपर्स को व्यवस्थापक विशेषाधिकारों के साथ सभी इकाई परीक्षण करने की गंदी आदत है।

9

महान विचार ... लेकिन अधिकांश कंपनियां आपको दो में से एक "अच्छा" मशीन भी नहीं देंगी।

— मैथ्यू Whited

1

आप VM में दूसरी मशीन 'मानक' बिल्ड के साथ कर सकते हैं। यह विशेष रूप से उपयोगी है यदि विकास नेटवर्क अपने स्वयं के डोमेन पर अलग हो जाता है। मुख्य डोमेन पर एक अलग उत्पादन वीएम नेटवर्क संसाधनों तक देवों की पहुंच देता है।

— ConcernedOfTunbridgeWells

5

यदि आप उस प्रश्न को उलटते हैं जो मुझे लगता है कि उत्तर देना आसान हो जाता है; क्या हमें डेवलपर्स से व्यवस्थापक अनुमतियाँ हटा देनी चाहिए? क्या है फायदा?

लेकिन वास्तव में, मुझे लगता है कि उत्तर आपके संदर्भ, आपके पर्यावरण पर निर्भर करता है। छोटे स्टार्टअप के पास आईएसओ-प्रमाणित सरकारी एजेंसी के लिए एक अलग जवाब होगा।

— एड Guiness
स्रोत

5

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

प्रोग्रामर के पास गैर-व्यवस्थापक उपयोगकर्ताओं के लिए सॉफ़्टवेयर लिखने के कठिन और तेज़ नियमों को जानने की भी ज़िम्मेदारी है। उन्हें वास्तव में पता होना चाहिए कि उन्हें कौन से सिस्टम संसाधनों का उपयोग करने की अनुमति हमेशा (या निषिद्ध) है। उन्हें इन संसाधनों को प्राप्त करने के लिए उपयोग किए जाने वाले एपीआई को जानना चाहिए।

"यह मेरी मशीन पर काम करता है" कभी कोई बहाना नहीं है!

— जॉन क्रॉमार्टी
स्रोत

5

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

एक तरफ ध्यान दें कि [साफ] सिस्टम या वीएम (एस) होना भी उचित है, ताकि आप सिस्टम को ट्विक करने के कारण चीजों को ठीक से परख सकें और "यह मेरे सिस्टम पर ठीक लगे / काम करता है" परिदृश्य में न आए।

— atom255
स्रोत

3

कोई पावर उपयोगकर्ता नहीं

सबसे पहले, पावर उपयोगकर्ता मूल रूप से एक प्रशासक है - इसलिए एक उपयोगकर्ता को पावर उपयोगकर्ता को " सीमित " करना सिस्टम में सुरक्षा में कोई वृद्धि प्रदान नहीं करता है - आप प्रशासक भी हो सकते हैं।

एक सामान्य उपयोगकर्ता के रूप में अंतःक्रियात्मक रूप से लॉग ऑन करें

दूसरे, बेशक एक डेवलपर को अपने डेवलपर मशीन (और सर्वर और दूसरे बक्से और इतने पर) तक प्रशासनिक पहुंच की आवश्यकता होती है, लेकिन निश्चित रूप से किसी को भी सामान्य विकास या परीक्षण के दौरान व्यवस्थापक के रूप में प्रवेश नहीं करना चाहिए। इसके और अधिकांश अनुप्रयोगों के लिए एक सामान्य उपयोगकर्ता खाते का उपयोग करें।

आप गंभीरता से एक प्रशासक के रूप में [किसी भी ब्राउज़र, प्लगइन, आईएम, ई-मेल क्लाइंट और इतने पर सम्मिलित] को चलाना नहीं चाहते हैं।

आप सामान्य रूप से अपने लिनक्स बॉक्स पर रूट के रूप में लॉग इन नहीं करते हैं, भले ही आपको इसकी आवश्यकता होने पर रूट एक्सेस की संभावना हो।

एक अलग व्यक्तिगत व्यवस्थापक खाते का उपयोग करें

अपने व्यक्तिगत मशीन (अधिमानतः) के लिए एक अलग व्यक्तिगत व्यवस्थापक खाते के साथ डेवलपर प्रदान करें जो कि अन्य देव / परीक्षण सर्वरों पर एक मान्य व्यवस्थापक है और उस व्यक्ति को प्रशासनिक पहुंच की आवश्यकता होती है।

"रन के रूप में" और विस्टा + यूएसी में शीघ्र या अनुरोध करने के लिए उपयोग करें और केवल आवश्यक होने पर कार्यों और प्रक्रियाओं के लिए प्रशासनिक क्रेडेंशियल्स दर्ज करें। स्मार्टकार्ड या समान के साथ पीकेआई अक्सर साख दर्ज करने में तनाव को कम कर सकता है।

हर कोई खुश है (या;)

फिर ऑडिट एक्सेस। इस तरह वहाँ पता लगाने की क्षमता है, और यह जानने का एक आसान तरीका है कि किसी विशेष देव / परीक्षण सर्वर पर टर्मिनल सेवा सत्रों का उपयोग कौन कर रहा है, जिसे आपको अभी एक्सेस करना है ...

दी, निश्चित रूप से ऐसे विकास कार्य हैं जिनके लिए कभी भी स्थानीय व्यवस्थापक विशेषाधिकारों की आवश्यकता नहीं होगी - जैसे अधिकांश वेब विकास जहां तैनाती को एक अलग सर्वर या वर्चुअल मशीन के खिलाफ परीक्षण किया जाता है और जहां कैसिनी या स्थानीय डिबगिंग के लिए जो कुछ भी उपयोग किया जाता है वह वास्तव में एक सामान्य उपयोगकर्ता के रूप में अच्छी तरह से चलता है।

— ऑस्कर डुवॉर्न
स्रोत

2

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

— NotMe

2

सामान्य लोगों को पैर में गोली मारने से रोकने के लिए यूएसी लगाया गया था। अगर कोई देव ऐसा करता है, तो उस पर शर्म करो। अगर वह लगातार ऐसा करता है तो उसे काम की एक और लाइन खोजने की जरूरत है।

— NotMe

यदि आप उन्हें कुंजी देते हैं तो आप वास्तव में उन्हें "हमें" स्वीकार करते हैं, प्रवेश के रूप में लॉग इन करने के लिए। यह सिर्फ इतना है कि रोजमर्रा के कार्यों के लिए यह एक अच्छा विचार नहीं है। क्यों लोगों को अभी भी लगता है कि यह सामान्य या आवश्यक है क्योंकि वे geeks, coders या admins मेरे से परे हैं।

— Oskar Duveborn

यदि आपने कभी देखा कि एक दिन में एक आधुनिक सिस्टम एडमिनिस्ट्रेटर क्या करता है, तो आपको एहसास होगा कि प्रशासनिक एक्सेस और वैकल्पिक क्रेडेंशियल दर्ज करने की आवश्यकता किसी भी हार्डकोर सिस्टम-स्तरीय कोडर की तुलना में अधिक है। वे अभी भी दिन-प्रतिदिन के कार्यों के लिए प्रशासक के रूप में लॉग ऑन नहीं करते हैं, और ठीक करते हैं।

— Oskar Duveborn

जब आप इसे प्रशासित कर रहे होते हैं तब भी आप सामान्य रूप से यूनिक्स प्रणाली में रूट नहीं करते हैं, तो आप विंडोज सिस्टम पर ऐसा क्यों करेंगे, भले ही आप डेवलपर हों? इसका कोई अर्थ नही बन रहा है। Skype या उच्च सिस्टम विशेषाधिकारों के साथ व्हाट्सएप जैसे सभी यादृच्छिक एप्लिकेशन चलाना कम से कम कहने के लिए अनभिज्ञ है - आपको केवल उन ऐप्स को ऊंचा करना होगा जिनकी आवश्यकता है।

— ओस्कर डुवॉर्न

3

मैं मुख्य रूप से * निक्स दुनिया में काम करता हूं और मानक मॉडल डेवलपर्स के लिए एक सामान्य, गैर-विशेषाधिकार प्राप्त उपयोगकर्ता खाते में काम करने की क्षमता (के माध्यम sudoसे su) के रूप में / जब आवश्यक हो तो विशेषाधिकारों को बढ़ाने के लिए है।

मुझे यकीन नहीं है कि समकक्ष विंडोज व्यवस्था क्या होगी, लेकिन यह मेरे अनुभव में आदर्श सेटअप है:

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

— डेव शेरोहमान
स्रोत

मुझे नहीं लगता कि मैंने एक व्यवसाय एप्लिकेशन का सामना किया है जो पिछले 5-10 वर्षों में एक सामान्य उपयोगकर्ता के रूप में नहीं चल सकता है। एक बार जब मैं एक BOFH था और उस जगह पर सभी उपयोगकर्ताओं को सामान्य उपयोगकर्ताओं के रूप में सब कुछ चलाने के लिए मजबूर किया गया था ~ 2001 के बाद से - कोई भी प्रशासक प्रत्यायोजित नहीं हुआ और इसने अच्छी तरह से काम किया और उस समय के बहुत सारे मालवेयर को विफल कर दिया। अगर हाल ही में इस तरह के एक विरासत ऐप चलाया जाता है (सैंडबॉक्स में इसे बेवकूफ बना रहा है) और मेरे दिन-प्रतिदिन के विकास के काम में भी स्वचालित शिम लागू होते हैं, तो यह केवल बहुत ही विजुअल स्टूडियो है जो मुझे संलग्न करने की आवश्यकता होने पर ऊंचा हो जाता है डिबगिंग के लिए अन्य प्रक्रियाओं के लिए।

— ओस्कर डुवॉर्न

3

[क्षमा याचना अंग्रेजी मेरी मातृभाषा नहीं है, मेरी पूरी कोशिश है :)] खैर,

व्यक्तिगत अनुभव (मैं एक c ++ / SQL देव):

मैं अपनी पिछली नौकरी में अपने विंडोज मशीन का एडमिन हुआ करता था। मैंने डेटाबेस पर डीबो (डीबीए नहीं) अधिकार भी दिए थे, जिसमें उत्पादन पर्यावरण डेटाबेस भी शामिल था। 2 और डेढ़ साल में 8 लोगों के पास ये पागल उच्च अधिकार हैं ... हमें कभी कोई परेशानी नहीं हुई। वास्तव में हमने db को मैन्युअल रूप से अपडेट करके बहुत सी समस्याओं का समाधान किया है। हम हॉट फ़िक्स और देवों के लिए वास्तव में बहुत तेज़ी से कर सकते हैं।

अब मैंने नौकरी बदल ली। मैं अपनी विंडोज़ मशीन का एडमिन बनने के लिए (बहुत रोने में) कामयाब रहा। लेकिन देव सर्वर एक रेड हैट सर्वर है जिसे हम ssh का उपयोग करके कनेक्ट करते हैं। क्यूटी को स्थापित करने की कोशिश करना एक यातना, कोटा सीमा, अंतरिक्ष सीमा, निष्पादन और अधिकार लिखना था। हमने आखिरकार हार मान ली और व्यवस्थापक से हमारे लिए ऐसा करने को कहा। 2 सप्ताह बाद भी कुछ भी स्थापित नहीं है। मैं अखबार पढ़ने और ऑल्ट + टैब हिटिंग पर वास्तव में तेज़ हो रहा हूं।

मैंने व्यवस्थापक अधिकारों के लिए कहा, क्योंकि मेरे नरम के देवता केवल इस मशीन का उपयोग करते हैं।

-> उत्तर: "यदि आप चाहते हैं कि आप जो भी करना चाहते हैं, उसके लिए प्रक्रियाएं हैं। इसे ठेस लगने पर एक बार ठीक करना होगा"।

-> एक गैर तकनीकी प्रबंधक को समझाने की कोशिश: "मेरे पास उत्पादन या UAT वातावरण में कोई भी अधिकार नहीं होगा। लेकिन मेरी देव मशीन अलग है। अगर मैं सॉफ्टवेयर्स के बजाय कुर्सियां बनाने के लिए था, तो क्या आप मुझे बताएंगे कि मैं। मेरी कार्यशाला में मुझे जो भी उपकरण चाहिए, वह नहीं डालेंगे क्योंकि मेरी कार्यशाला को उस जगह की तरह दिखना होगा जहाँ कुर्सी का उपयोग किया जाएगा? मैं ऊट के लिए एक निष्पादन योग्य पैकेज देता हूँ। मैंने जो निर्माण करने के लिए उपयोग किए थे, वे जो लिबास और उपकरण थे, वे अंतिम उपयोगकर्ता के लिए अदृश्य हैं। दोस्त पैकेज स्थापित कर रहा है। "

मैं आज भी इंतजार कर रहा हूं। मुझे एक समाधान मिला, एक देव दूत खोलें, अपने पसंदीदा ऑनलाइन जज के पास जाएं, अपने आप को चुनौती दें। जब कोई आपकी स्क्रीन को देखता है, तो वह आपको प्रोग्रामिंग करते हुए देखेगा। ;)

2

इसका जवाब आप दो तरह से दे सकते हैं। हां और नहीं, या यह निर्भर करता है। - क्या मैं ज्यादा अस्पष्ट हो सकता हूं ...।

यह निर्भर करता है कि उनके लिए अपना काम करना आवश्यक है या नहीं। यदि यह है तो उन्हें अपने कंप्यूटर पर प्रशासनिक शक्तियां प्रदान करें। यदि नहीं तो नहीं। सभी सॉफ़्टवेयर विकास के लिए व्यवस्थापक अधिकारों के लिए एक इंजीनियर की आवश्यकता नहीं होती है।

हां और नहीं आपके विचार पर निर्भर करता है। कुछ इंजीनियर अपने कंप्यूटर को अपने डोमेन के रूप में देखते हैं और वे अपने डोमेन के नियम हैं। दूसरों को जिम्मेदारी नहीं चाहिए।

मैंने एक कंपनी में काम किया है, जहाँ मेरे पास व्यवस्थापक अधिकार नहीं थे और जब भी मुझे कुछ ऐसा करने की आवश्यकता होती थी, जिसके लिए व्यवस्थापक अधिकारों की आवश्यकता होती थी, तो मुझे हेल्प डेस्क पर कॉल करना पड़ता था और जब तक मैंने रिबूट नहीं किया, उन्होंने मुझे अस्थायी व्यवस्थापक अधिकार प्रदान कर दिया। यह कई बार एक दर्द था, लेकिन यह वैसा ही था जैसा कि मैं इसके साथ रहता था। मैंने उन स्थानों पर भी काम किया है, जहां मुझे अपने कंप्यूटर पर पूर्ण अधिकार प्राप्त हैं। यह उस समय के अलावा बहुत अच्छा था जब मैंने कुछ सॉफ्टवेयर स्थापित किए जो ओएस को बंद कर दिया और मेरे कंप्यूटर को हेल्प डेस्क पर ले जाना पड़ा और उन्हें हार्ड ड्राइव को फिर से इमेज करना पड़ा ...।

मुझे व्यक्तिगत रूप से लगता है कि एक इंजीनियर को अपने कंप्यूटर पर व्यवस्थापक अधिकार होना चाहिए, लेकिन इस समझ के साथ कि अगर वे इसे खराब कर देते हैं तो एक नई बेसलाइन छवि फिर से लोड की जा सकती है और वे मूल बेसलाइन के बाद से कुछ भी खो देंगे। मेरा मानना है कि किसी कंपनी में सभी को अपने कंप्यूटर पर व्यवस्थापक अधिकार होना चाहिए। लेखांकन, प्रशासनिक सहायकों और अन्य विभागों को वास्तव में उन अधिकारों को रखने की आवश्यकता नहीं है, इसलिए उन्हें अनुमति नहीं दी जानी चाहिए।

— निशान
स्रोत

मैं एक कंपनी के लिए एक बार ठेकेदार था, जिसमें व्यवस्थापक अधिकार प्राप्त करने के लिए, मुझे एक पावती पर हस्ताक्षर करना था कि आईटी कर्मचारी दस या पंद्रह मिनट से अधिक खर्च नहीं करेगा, जो मेरे कंप्यूटर को ठीक करने की कोशिश कर रहा है और फिर पूरी तरह से मिटा देगा और फिर से करेगा -image। यह मुझे उचित लगा।

— डेविड थोरले

माना। महान शक्ति के साथ महान जिम्मेदारी आती है।

— क्रेगटीपी

2

ht tp: //msdn.microsoft.com/en-us/library/aa302367.aspx

मेरे अनुभव में, हमारे (कोडर्स) और उन्हें (सुरक्षा) के बीच एक समझौता की हमेशा जरूरत होती है। मैं मानता हूं (हालांकि मुझे इससे नफरत है), ऊपर के Microsoft लेख में योग्यता है। जैसा कि मैं वर्षों से एक प्रोग्रामर रहा हूं, मैंने उस दर्द का अनुभव किया है, जहां मुझे एक अलग डिबगर स्थापित करने की आवश्यकता थी, बस मैं नाराज नहीं हो सकता। इसने मुझे अपना काम करने के तरीके में रचनात्मक सोचने के लिए मजबूर किया। हमारी सुरक्षा टीम (और कई चर्चाओं) से जूझने के वर्षों के बाद, मैंने अपने डेस्कटॉप सहित सभी क्षेत्रों को सुरक्षित करने के उनके काम को समझा। उन्होंने मुझे दैनिक कमजोरियों को दिखाया, जो सबसे सरल क्विकटाइम ऐप पर भी सामने आती हैं। मैं हर बार उनकी फ्रूटेशन देख सकता हूं मैं एक त्वरित उपयोगिता स्थापित करना चाहता हूं या अपने स्थानीय IIS को ट्वीक करना चाहता हूं कि मैं एक गंभीर सुरक्षा समस्या पैदा कर सकता हूं। जब तक मैंने किसी अन्य डेवलपर को डिब्बाबंद होते हुए नहीं देखा, मैं इसे पूरी तरह से समझ नहीं पाया। वह डिबग करने की कोशिश कर रहा था और सैकड़ों लोगों को कुछ वायरस लाने के लिए सिमेंटेक को बंद कर दिया और समाप्त कर दिया। वहाँ गड़बड़ थी। जो हुआ, उसके बारे में "सेकेड्स" (सुरक्षा लोगों) में से एक से बात करने में, मैं देख सकता था कि वह सिर्फ यह कहना चाहता था, "आपको ऐसा बताया ..."।

मैंने सीखा है कि हमारे सेशेड्स (अच्छी तरह से, कम से कम मेरा) बस हमारी कंपनी की रक्षा करना चाहते हैं। अच्छी खबर यह है कि हमने एक समझौता किया, और मैं अपना काम पूरा कर सकता हूं और सेशेड हमारे सुरक्षित नेटवर्क के साथ शांत हैं!

पंथ

1

हां यदि आप चाहते हैं कि आपके डोमेन से समझौता करने पर पैरेंटर्स या कुछ कुशल दुर्भावनापूर्ण उपयोगकर्ता प्राप्त करें।

यानी कम स्तर के खाते का पता लगाएं> पता लगाएं कि कहां व्यवस्थापक -> Mimikatz -> प्रासंगिक अनुमतियाँ -> डोमेन व्यवस्थापक।

तो नहीं, सामान्य उपयोगकर्ताओं को प्रवेश नहीं होना चाहिए।

साथ ही Microsoft ने कहा है कि UAC एक सुरक्षा सीमा नहीं है, इसलिए इसे इस तरह से उपयोग न करें। यूएसी के विभिन्न वास्तविक विश्व बाईपास उपलब्ध हैं।

अगर उन्हें अपनी नौकरी की भूमिका के रूप में व्यवस्थापक की आवश्यकता है, तो केवल सॉफ्टवेयर स्थापित करने के लिए उपयोग किए जाने वाले अलग-अलग डोमेन स्थानीय व्यवस्थापक उपयोगकर्ता खाते दें (केवल अपनी मशीन पर व्यवस्थापक अनुमतियों के साथ), सामान्य उपयोग या इंटरनेट एक्सेस के लिए कभी नहीं। इसके लिए एक अधिक कठोर पासवर्ड नीति होनी चाहिए (जैसे 15 वर्ण न्यूनतम लंबाई)। इसके लिए रनस कार्यक्षमता का उपयोग किया जाना चाहिए।

कोई भी वातावरण जहाँ सामान्य उपयोगकर्ता खाते हैं व्यवस्थापक सुरक्षा सुरक्षा के लिए एक नुस्खा है।

— SilverlightFox
स्रोत

0

वाह, यह सवाल निश्चित रूप से कुछ दिलचस्प जवाबों को खोलने वाला है। जवाब में मैं इस्तेमाल किए गए टोट के उद्धरण - 'यह निर्भर करता है' :)

छोटी कंपनियों में यह सिर्फ व्यावहारिक होने की बात हो सकती है। डेवलपर्स भी सबसे अधिक तकनीकी रूप से निपुण होने की संभावना रखते हैं, इसलिए यह उनके लिए अपनी मशीनों को प्रशासित करने के लिए समझ में आता है।

व्यक्तिगत रूप से, मैं "एडमिन अकाउंट" का प्रशंसक हूं, जिसका उपयोग आवश्यक होने पर किया जा सकता है - यानी "रन अस .." (मैंने देखा कि यह दृष्टिकोण बाद में यूएसी के प्रमुख के समान था)।

यदि आप डेस्कटॉप सॉफ़्टवेयर विकसित कर रहे हैं, तो यह डेवलपर्स के लिए एक बुरा विचार नहीं है कि वे इस सीमा के भीतर काम करें कि उनके अंतिम उपयोगकर्ता का अनुभव होगा - यानी सीमित या प्रतिबंधित अधिकार। यदि आप सीमित अधिकारों के तहत सॉफ़्टवेयर का निर्माण करते हैं, तो यह एक अच्छा मौका है कि आप वही समस्याएँ मारेंगे जो आपके लक्षित उपयोगकर्ताओं को अनुमतियों के समान सेट के सामने आती हैं।

यह कहने के बाद कि, यदि आपके पास एक अच्छा परीक्षण प्रयोगशाला और / या एक सभ्य क्यूए टीम है तो यह एक मूक बिंदु हो सकता है - खासकर यदि आपके पास एक आधा सभ्य एएलएम अभ्यास है।

तो अंत में - मैं यूएसी के बिना विकसित होता हूं, मुख्यतः क्योंकि मुझे खुद पर और अपने कौशल पर भरोसा है। एक टीम के माहौल में, मैं इसे एक वोट के लिए डालूँगा। बड़े संगठनों में आपको यह स्वतंत्रता नहीं मिल सकती है .. एंटरप्राइज एडमिन्स का अक्सर अंतिम कहना होता है :)

— लूटता
स्रोत

0

मेरी कंपनी में, डेवलपर्स, इंजीनियर और मेरे बॉस (कंपनी के मालिक) को स्थानीय व्यवस्थापक विशेषाधिकार प्राप्त हैं। मेरे बॉस को नेटवर्क एडमिन विशेषाधिकार भी है, बस अगर मैं उस तरह की बस (या छोड़) से प्रभावित हो जाता हूं। बाकी सब लोग बंद हो जाते हैं।

Sysadmin के रूप में, इस सेटअप ने मुझे समय-समय पर थोड़ा दु: ख दिया है, खासकर जब अप्रयुक्त सॉफ्टवेयर स्थापित हो जाता है। हालाँकि, डेवलपर पृष्ठभूमि से आने के बाद, मैं समझता हूं कि बिजली उपयोगकर्ताओं को अपने पर्यावरण पर अधिक नियंत्रण रखने की आवश्यकता है और इस तरह, कभी-कभार होने वाली समस्या या सतह पर आने वाली समस्या से निपटने के लिए तैयार हूं। मैं उनके वर्कस्टेशन्स का रुटीन बैकअप करता हूँ - सिर्फ मामले में।

वैसे, मुझे बॉस के साथ किसी और के साथ चीजों के साथ छेड़छाड़ करने के साथ और अधिक समस्याएं हैं। पुराने सवाल की तरह, "एक हाथी कहाँ बैठता है? कहीं भी वह चाहता है!" लेकिन एक छोटी सी फर्म में, जहां वह अनिवार्य रूप से "बैकअप" sysadmin है, वहाँ ज्यादा विकल्प नहीं है।

— माइक
स्रोत

-1

यह डेवलपर कौशल पर निर्भर करता है और कि क्या वह एक सलाहकार है या नहीं।

मुझे लगता है कि यह उचित है कि एक अनुभवी और भरोसेमंद डेवलपर को उसके / उसके पीसी के साथ जो कुछ भी करने का अधिकार है, जब तक वह उसे / उसकी उत्पादकता को नुकसान नहीं पहुंचाता है।

— मैरिकिको कोराज़ी
स्रोत

6

आप एक सलाहकार और नियमित कर्मचारी के हाथ क्यों बाँधेंगे? क्या वे दोनों एक ही काम नहीं कर रहे हैं? क्या आप सलाहकार से कम की उम्मीद करते हैं, भले ही आप उनके लिए अधिक भुगतान करने की संभावना रखते हैं? यह वास्तव में गूंगा लगता है। इसके अलावा, अगर एक देव अपनी मशीन चालू नहीं रख सकते हैं तो उन्हें एक नई नौकरी की आवश्यकता होती है

— NotMe

-1

विंडोज एक्सपी पर कोई भी दिन-प्रतिदिन के उपयोग के लिए एक व्यवस्थापक खाते का उपयोग नहीं करना चाहिए, और यदि आपको कम से कम यूएसी सक्षम होना चाहिए, तो विस्टा में। विशेष रूप से वेब डेवलपर्स और अन्य डेवलपर्स जो इंटरनेट एक्सप्लोरर के साथ वेब ब्राउज़ करते हैं।

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

— Bratch
स्रोत