Если разработчики имеют права администратора на своем ПК

Это зависит от навыков разработчика и является ли он или она консультантом или нет.

Я думаю, что разумно, что закаленный и защищенный разработчик имеет права сделать независимо от того, что он или она хочет с ее/его ПК, пока это не вредит ее/его производительности.

Ничего себе, этот вопрос, конечно, собирается открыть некоторые интересные ответы. В ответ я заключаю в кавычки часто используемый - 'Это Зависит' :)

В небольших компаниях это могло бы просто быть просто вопросом того, чтобы быть прагматичным. Разработчики, также, вероятно, будут наиболее технически знаток, таким образом, это будет иметь смысл для них к adminster их собственные машины.

Лично, я - поклонник "администраторской учетной записи", которая может использоваться когда необходимый - т.е. "Выполненная Как.." (Я заметил, что этот подход был очень похож в принципале на контроль учётных записей позже).

При разработке программного обеспечения, установленного на компьютере, это не плохая идея для разработчиков работать в рамках ограничений, которые их конечный пользователь испытает - т.е. ограниченные или ограниченные права. При создании программного обеспечения под ограниченными правами это - хороший шанс, что Вы поразите те же проблемы, с которыми Ваши целевые пользователи столкнулись бы, учитывая тот же набор полномочий.

Однако если у Вас есть хорошая лаборатория тестирования, и/или достойный QA объединяются в команду, это могло бы быть спорным вопросом - особенно, если у Вас есть половина достойной практики ALM.

Таким образом, наконец - я разрабатываю без контроля учётных записей, главным образом потому что я доверяю мне и моим навыкам. В среде команды я поместил его в голосование. В более крупных организациях у Вас не могло бы быть этой свободы.. Администраторы Предприятия часто имеют последнее слово :)

Можно ответить на это двумя способами. Да и не, или это зависит. - Я могу быть более неопределенным....

Это зависит, если это требуется для них сделать их задание. Если это, затем предоставляют им административные полномочия по их компьютеру. Если не затем не делают. Не вся разработка программного обеспечения требует, чтобы у инженера были права администратора.

Да и не зависит от Вашего представления. Некоторые инженеры просматривают свой компьютер как их домен, и они - правила своего домена. Другие не хотят ответственности.

Я работал в одной компании, где у меня не было прав администратора и каждый раз, когда я должен был сделать что-то, что потребовало прав администратора, которые я должен был назвать справочной службой, и они предоставили мне временные права администратора, пока я не перезагрузил. Это время от времени было болью, но это было способом, которым это было так, я жил с ним. Я также работал в местах, что у меня есть полные права администратора к моему компьютеру. Это было большим за исключением времени, я установил некоторое программное обеспечение, которое полило из шланга ОС и должно было взять мой компьютер к справочной службе и сделать, чтобы они повторно отобразили жесткий диск....

Я лично чувствую, что у инженера должны быть права администратора к их компьютеру, но с пониманием, что, если они завинчивают его затем, новое базовое изображение может быть перезагружено и они потеряют что-либо, что было сделано начиная с исходной базовой линии. Я не полагаю, что у всех в компании должны быть права администратора к их компьютеру как бы то ни было. При учете у помощников по административным вопросам и других отделов действительно нет потребности иметь те права, таким образом, их нельзя предоставить.

Я работаю, прежде всего, в *, отклоняют мир и стандартную модель, там, чтобы разработчики работали в нормальной, непривилегированной учетной записи пользователя со способностью (через sudo или su) возрастать к административным привилегиям как/когда необходимые.

Я не уверен, каково эквивалентное расположение Windows было бы, но это - по моему опыту, идеальная установка:

• С одной стороны, имение в наличии прав администратора по требованию дает полную мощность разработчика по его рабочей станции при необходимости.

• На другом программное обеспечение Windows имеет длинную, долгую историю предположения, что у всех пользователей есть права администратора, до такой степени, что много программ не будут работать за неадминистраторским пользователем. Многие проблемы безопасности Windows происходят непосредственно от этого неявного требования, чтобы, чтобы смочь надежно использовать компьютер, все пользователи были администраторами. Это должно измениться и самый эффективный способ гарантировать, что Ваше программное обеспечение будет работать за неадминистраторскими пользователями, чтобы Ваши разработчики выполнили его сами как неадминистраторские пользователи.

Никакой продвинутый пользователь

В первую очередь, Продвинутый пользователь является в основном администратором - настолько "ограничивающий" пользователь Продвинутому пользователю не обеспечивает увеличения безопасности к системе - Вы могли бы также быть администратором.

Войдите в систему в интерактивном режиме как обычный пользователь

Во-вторых, конечно, разработчику нужен административный доступ к их машине разработчика (и серверы и вторые поля и так далее), но конечно никто не должен в интерактивном режиме входить в систему как администратор во время нормальной разработки или тестирования. Используйте счет обычного пользователя на это и большинство приложений.

Вы серьезно не хотите работать [вставляют любой браузер, плагин, IM, Почтовый клиент и так далее] как администратор.

Вы обычно не входите в систему свое поле Linux как корень также, даже если у Вас, вероятно, есть корневой доступ при необходимости в нем.

Используйте отдельную персональную учетную запись администратора

Предоставьте разработчику отдельную персональную учетную запись администратора к его машине (учетная запись домена предпочтительно), который является также допустимым администратором на других dev/test серверах и полях, к которым человек нуждается в административном доступе.

Используйте "выполненный как" и в Vista + контроль учётных записей, чтобы запросить или запросить подсказку и ввести административные учетные данные для задач, и обрабатывает только при необходимости. PKI со смарт-картами или подобный может значительно уменьшить деформацию во вводе учетных данных часто.

Все счастливы (или?;)

Затем контрольный доступ. Таким образом, там является трассируемость и простой способ узнать, кто использует сессии служб удаленных рабочих столов на конкретном dev/test сервере, который Вы имеете к праву доступа теперь...

Предоставленный, существует определенно техническая разработка, которая никогда не будет требовать полномочий локального администратора - как большая часть веб-разработки, где развертывание тестируется против отдельного сервера или виртуальной машины и куда Кассини или независимо от того, что используется для локальной отладки на самом деле, работает хорошо как обычный пользователь.

Как системный администратор я - все для разработчиков, имеющих локальные права администратора на их рабочих станциях. Когда возможно, это не плохая идея сделать большинство вещей со стандартной 'пользовательской' учетной записью уровня и затем использовать другую 'администраторскую' учетную запись для внесения изменений, приложения установки и т.д. Часто Вы можете sudo или руны для выполнения то, что Вы хотите без того, чтобы даже выходить из системы. Также полезно напомнить нам о том, что швыряет безопасность, конечные пользователи должны будут перейти через при выпуске к производству.

На стороне отмечают, что также желательно иметь [чистую] систему или VM (s) так, чтобы можно было протестировать вещи правильно и не войти, "это смотрит/хорошо работает в моей системе" сценарий из-за системной тонкой настройки.

Если Вы инвертируете вопрос, я думаю, что становится легче ответить; мы должны удалить права администратора от разработчиков? Каково усиление?

Но на самом деле, я думаю, что ответ зависит от Вашего контекста, Вашей среды. Маленький запуск будет иметь другой ответ сертифицированному ISO правительственному учреждению.

Абсолютно! Как еще я установил бы менеджер загрузок для скачивания фильмов ночью?

Иногда разработчики действительно должны установить вещи или изменить что-то в системе для проверения некоторой идеи. Будет невозможно, если необходимо назвать администратора каждым разом, когда необходимо изменить что-то.

У меня также есть свое персональное наблюдение, что некоторые администраторы склонны завинчивать трудный все, что возможно, чтобы заставить даже небольшие вещи зависеть от них ежедневно таким образом... что, защитив их задание? беся других пользователей? Не имейте никакого ответа. Но здравый смысл не замечен здесь.

Прошлый раз был проблемой с моим ПК, я принял активное участие в восстановлении системы, делая некоторые предложения, работающие в команде с администратором, или таким образом, я думал... Администратор, превращенный, чтобы быть очень сердитым и, обвинил меня в попытке преподавать его или переопределить правила. Я предполагаю, что это было просто его эго, поскольку он не был замечен что прохладный в нашей комнате среди других коллег.

Разработчики обычно должны делать вещи, что средний человек не был бы и так должен обычно иметь учетные записи администратора. Создание их скачкообразно двинуться через неловкие обручи тратит впустую их время и деморализует их. Могут быть исключения в ситуациях высокой безопасности, но если Вы не можете доверить кому-то администраторскую учетную запись, Вы уверенный не можете доверять их коду.

У них должна также быть доступная учетная запись того же разрешения как их пользователи (больше чем одна учетная запись, если объединение пользователей имеет различные состояния разрешения). Иначе они могут просто разработать что-то прохладное, развернуть его и затем найти, что оно не будет работать на пользователей.

Существует также слишком много способов завинтить компьютеры с администраторскими учетными записями (да, я сделал это). Отделу ИТ нужна политика, что они повторно отобразят компьютер разработчика, если они не могут зафиксировать его быстро. В одном месте я заключил контракт в, я должен был подписать копию той политики получить мою администраторскую учетную запись.

Это - довольно определенный для Windows ответ. В Linux и других системах Unix-y, разработчики могут чаще обходиться учетными записями пользователей только, часто не нуждаются в другом счете на тест (если у них есть учетная запись, они могут sudo с, они действительно знают, когда они используют sudo, но им, возможно, понадобится один с теми же полномочиями группы), и может сделать невероятные суммы повреждения ОС очень легко, таким образом, та же политика IT необходима.

Локальный администратор да, по всем вышеизложенным причинам. Сетевой администратор не, потому что они будут неизбежно вовлечены в задачи администрирования сети, потому что "они могут". Devs должен разрабатывать. Администрирование сети является совершенно другим заданием.

Да и нет.

Да, это экономит много времени, беспокоя системную поддержку.

Нет, у Ваших пользователей нет его, так не рассчитывайте на него.

Мы разрабатываем с администраторскими полномочиями и тестом без. Который разрабатывает право.

Никто на Windows XP не должен использовать счет администратора на ежедневное использование, и в Vista, если необходимо быть администратором, по крайней мере, включили контроль учётных записей. Особенно веб-разработчики и другие разработчики, которые просматривают веб-сайты с Internet Explorer.

То, что можно сделать, сделали, чтобы разработчики использовали свою учетную запись обычного пользователя, но сделали им второй отчет, который является администратором на их ПК, таким образом, они могут использовать его по мере необходимости (Выполнение Как). Я знаю, что они сказали, что веб-разработка, но для разработки Windows Ваше программное обеспечение должно быть протестировано с помощью учетной записи обычного пользователя, не как администратор.

Разработчики должны иметь полный и полный контроль над машиной, которую они используют. Большинство средств отладки требует администраторских полномочий для сцепления во время выполнения приложения, которое они создают.

Далее, devs часто загружают и пробуют новые вещи. Добавление дополнительных шагов, таких как необходимость в сетевом администраторе, чтобы прибыть и установить что-то для них просто разбивает dev и быстро сделает жизненный ад для сетевого человека операции в секунду.

Тем не менее они должны быть администратором на СВОЕМ поле, не сетью.

Да, но они должны знать об ограничениях, с которыми их пользователи столкнутся когда под управлением программное обеспечение в более ограниченной среде. У разработчиков должен быть легкий доступ к "типичным" средам с ограниченными ресурсами и полномочиями. В прошлом я включил развертывающиеся сборки к одной из этих "типичных" систем (часто VM на моей собственной рабочей станции) как часть процесса сборки, так, чтобы я мог всегда получать быстрое ощущение того, как программное обеспечение работало над машиной конечного пользователя.

Программисты также несут ответственность знать твердые правила записи программного обеспечения для неадминистраторских пользователей. Они должны знать точно, какие системные ресурсы им всегда позволяют (или запрещают) к доступу. Они должны знать API, которые используются для получения этих ресурсов.

"Это работает над моей машиной", никогда не оправдание!

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

In my experience, a compromise between us (coders) and them (security) is always needed. I admit (though I hate to), there is merit in the Microsoft article above. As I have been a programmer for years, I have experienced the pain where I needed to just install a different debugger, just to get annoyed I can't. It forced me to think creatively in how to get my job done. After years of battling our security team (and several discussions), I understand their job of having to secure all areas, including my desktop. They showed me the daily vulnerabilities that come out, even on the simplest Quicktime app. I can see their frutration everytime I want to install a quick utility or tweak my local IIS that I can cause a serious security problem. I didn't fully understand this until I saw another developer get canned. He was trying to debug and ended up shutting off Symantec only to get (and then GIVE) some virus to hundreds of people. It was a mess. In talking to the one of the "secheads" (security guys) about what happened, I could see he wanted to just say, "told you so...".

I have learned that our secheads (well, at least mine) just want to protect our company. The good news is we did find a compromise, and I can get my job done and the secheads are cool with our secure network!

Creed

Да, Half-Life 1 (и все связанные с ним моды: counter-strike, день поражения и т. Д.) Нуждаются в правах администратора (по крайней мере, для первого запуска, я думаю) для работы правильно в Windows NT, 2000, XP и т.д.

И какой разработчик не играет в Counter Strike в обеденное время? (паршивый точно)

В моей компании разработчики, инженеры и мой босс (владелец компании) имеют права локального администратора. У моего босса также есть привилегия сетевого администратора, на случай, если меня сбьет этот своенравный автобус (или я уйду). Все остальные будут заблокированы.

Как системный администратор, эта установка время от времени доставляла мне небольшие неприятности, особенно когда устанавливается неутвержденное программное обеспечение. Однако, имея опыт разработки, я понимаю, что опытным пользователям необходимо иметь больший контроль над своей средой, и поэтому я готов мириться с случайными причудами или проблемами, которые могут возникнуть. Я делаю рутинное резервное копирование их рабочих станций - на всякий случай.

Между прочим, у меня было больше проблем с боссом, который возился с вещами, чем с кем-либо еще. Вроде как старый вопрос " Где сидит слон? Куда угодно он хочет! " Но в небольшой фирме, где он, по сути, «резервный» системный администратор, особого выбора нет.

Перенес боль разработки без прав администратора на машине, я могу ответить только да, это важно.

Ответ: у разработчиков должно быть 2 машины !!

• Одна машина для разработки с правами администратора, достаточной мощностью, памятью, размером экрана, переносимостью и привилегиями ADMIN с корпоративным антивирусом. программное обеспечение загружается, но настраивается разработчиком при необходимости с политикой автоматического сброса.

• Один корпоративный, который имеет корпоративную нагрузку, политики, права пользователя без прав администратора и т. д. Разработчик может использовать его для модульного тестирования приложений в режиме выпуска, как некоторые разработчики имеют неприятную привычку проводить все модульное тестирование с правами администратора.