I diritti utente "Utente" sono sufficienti o gli sviluppatori necessitano di Amministratore locale o Power User durante la codifica?

Un programmatore dovrebbe funzionare come utente con accesso amministrativo. Cioè, il programmatore dovrebbe essere l'amministratore della macchina, ma mentre lavora, dovrebbe sempre usare un account utente limitato.

Se hai bisogno di diritti elevati per lavorare, per qualsiasi cosa tranne l'installazione di software, stai facendo qualcosa di molto sbagliato. Peggio ancora, se lavori come un utente esperto o disattiva i prompt UAC o simili, stai ignorando i problemi che potrebbero interessare gli utenti finali del tuo software, forzandoli a eseguire gli stessi privilegi che hai fatto. Questo è sbagliato.

Questo è vero, indipendentemente dal sistema operativo in uso. Anche se Windows sembra essere l'unico in cui si trova.

Per chiarire:

Quando dico che lo sviluppatore dovrebbe essere un utente limitato, voglio dire che dovrebbero avere i diritti di amministratore completi sulla macchina, ma quando testano il loro codice, dovrebbero essere fatti in un ambiente con un numero limitato di utenti. Ad esempio, lo sviluppatore potrebbe utilizzare la macchina come utente abilitato all'amministrazione, ma esegue tutti i test in una macchina virtuale o in un account utente limitato. Su Linux, questo significa semplicemente che lo sviluppatore ha accesso sudo ; su Windows, questo può significare un account a livello di amministratore con UAC e altre funzionalità di sicurezza completamente abilitate.

Questo è un problema politico o di gestione, non tecnico.

Considera la possibilità di creare e comunicare una regola "non vogliamo che installi software non pertinente alla tua funzione di lavoro", in modo che il capo possa seguire di conseguenza.

Per facilitare questo, l'amministratore di sistema può chiedere ad ogni macchina un elenco di programmi installati. Se lo fai regolarmente, puoi scrivere un piccolo programma per mostrare cosa è stato installato, in modo da ottenere una rapida panoramica.

Detto questo, a meno che i suddetti programmi siano illegali o moralmente inaccettabili, allora perché questo è un problema in primo luogo?

Dipende da cosa ti aspetti che si sviluppi in modo indipendente.

Alcune cose come la configurazione di IIS, il debug remoto, la modifica dell'accesso al GAC, la possibilità di eseguire il proprio MSI sarebbero sicuramente influenzate. Se queste sono le cose che ci si aspetta che le risorse esternalizzate facciano in modo indipendente, non la tenterei senza un sacco di test.

Se i tuoi collaboratori esterni lavorano su un'app desktop che possono eseguire il debug in locale, probabilmente la faranno franca con pochi problemi.

Supponendo che stiano utilizzando il controllo del codice sorgente, è sempre possibile pianificare periodicamente la ri-immagine delle macchine.

La maggior parte dei posti in cui ho lavorato fa parte del primo caso e si aspetta un'elevata indipendenza, quindi tutti gli sviluppatori sono amministratori locali e la politica aziendale consente misure disciplinari se si installa software non approvato su qualsiasi macchina e si verificano problemi.

Ho bisogno dei diritti di amministratore per accendere Apache sulla porta 80 del mio MacBook di sviluppo. A parte questo, non c'è motivo per cui non potrei essere su una macchina bloccata senza diritti di amministratore. E potrei usare una porta non standard, se davvero ne avessi bisogno. Dal punto di vista delle risorse aziendali, ha senso che gli sviluppatori non siano utenti privilegiati delle loro macchine.

Tuttavia, il blocco di uno sviluppatore sulla propria macchina deve essere accompagnato da un team di amministratori reattivo e disponibile. Se non riesco a installare roba da solo, ho bisogno di qualcuno che possa farlo per me, ma senza farmi passare tre cicli di documenti di approvazione. Se l'azienda non è disposta a impegnarsi in tal senso, allora dovrebbe dare agli sviluppatori la piena esecuzione del loro boxen.

Preferisco quest'ultimo, ovviamente, ma posso vedere la saggezza del primo.

Gestisco VS 2010 non come amministratore per la maggior parte del tempo. Ma se vuoi aggiungere o rimuovere un servizio, configurare IIS, o modificare il registro, hai bisogno dei diritti di amministratore. Inoltre alcuni strumenti di profilazione ti spingono a riavviare VS come amministratore. Quindi penso che dare dei conti alle persone offshore che non hanno poteri amministrativi impedirà loro di fare alcune (forse piccole) parti del loro lavoro.

Inoltre, con l'aumento del controllo dell'account utente, sempre più app possono ora essere installate senza poteri di amministrazione. Non inseriscono oggetti in HKLM, non toccano nulla in System32, mettono l'exe da qualche parte nella cartella users \ whoever, e questo li rende molto più facili da rimuovere ma potrebbero non indirizzare il punto originale che stanno installando " software senza senso "con cui presumo tu intenda giochi, lettori musicali ecc.

Se vuoi davvero evitare installazioni locali, forse la scommessa migliore è la vecchia visione di "la rete è il computer" dai primi giorni di Java. Tutti lavorano da un sistema di controllo delle versioni e devono effettuare il check-in o il deposito ogni notte prima di andare a casa. L'email vive nel cloud non sulla macchina di sviluppo. Ecc. Poi, quando vuoi, puoi ri-visualizzare le loro macchine dev (ancora più semplice se sono virtuali) e quelli che non hanno installato nulla di extra non se ne accorgeranno nemmeno. Un po 'come pulire il frigorifero dell'ufficio durante il fine settimana.

Ma attenzione: non lavorerei in quell'ambiente. Installo utilità e aiutanti, e gioco occasionalmente, e non prendo piacere a qualcuno che ha cercato di impedirlo. Sono produttivo da morire. Se alcuni dei tuoi sviluppatori non sono produttivi, portare via le loro installazioni locali non li renderà più produttivi o dedicati. Affronta il problema alla radice e non ti dispiacerà che siano amministratori.

Suppongo che la rimozione dei diritti di amministratore dagli sviluppatori dovrebbe venire insieme all'assegnazione di uno degli amministratori di sistema per installare il software per il team. Se non possiedi entrambi i diritti di amministratore e non puoi chiedere all'amministratore di installare cose per te, sei semplicemente senza mani di fronte alle sfide che stai affrontando. È come se bloccassi la tua squadra offsore in prigione.

Dipende da cosa stai scrivendo il software.

Se il tuo software non ha bisogno di intrude nel tuo sistema, non c'è bisogno di poteri di amministratore.

Una soluzione migliore: per scopi di installazione / test, è possibile utilizzare VM o computer di prova.

Ho visto due approcci a questo. Uno era far lavorare tutti da computer portatili, che dovevano consegnare agli amministratori quando tornavano a casa. Una volta che l'amministratore l'ha avuta, si sarebbero incollati in un CD che reimmaginerebbe la macchina. Una volta reimaging, è andato su uno scaffale, dove sarebbe stato disponibile per la prossima persona che ne aveva bisogno. Assicurati che tutte le macchine siano identiche, in modo che non finisca con le persone che le sfiorano cercando un "buono".

L'altra cosa che ho visto è far avviare tutti da un server Citrix. Le macchine non hanno alcuna memoria locale, caricano semplicemente un'immagine standard dalla rete e ne escono. Funziona meglio se hai "tipi" diversi di utenti che richiedono configurazioni diverse (ad esempio, gli sviluppatori dell'interfaccia utente hanno un'immagine con Silverlight, gli sviluppatori di WCF hanno IIS e SQL Server, ecc.)

MA, con tutto ciò che ho detto, penso che Thorbjorn [sic] abbia centrato la testa: questo è un problema di gestione e probabilmente non sarà affrontato adeguatamente con una soluzione tecnica.