Назад | Перейти на главную страницу

Группы и разрешения: вложенные группы UNIX

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

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

ourcompany: xxx: john, joe, bob guestcompany: xxx: guest1, guest2, @ ourcompany

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

(Причина, по которой мне не нужна guestcompany: xxx: guest1, guest2, john, joe, bob, заключается в том, что если мы добавляем или удаляем людей из нашей компании, то кому-то придется пройти и убедиться, что все обновлено, что, вероятно, может упасть с края)

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

Я не предлагаю вам делать это таким образом, но я решил эту проблему, используя Active Directory для управления моей централизованной аутентификацией и реализовал Likewise Open для аутентификации моих машин Linux. LWO дает согласованные UID и GID на всех машинах, потому что они основаны на хеш-коде. Это упрощает работу с такими вещами, как NFS и rsync. Он также прекрасно решает вложенные группы.

Используете ли вы какую-либо централизованную аутентификацию, например NIS или LDAP?

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

Я бы рекомендовал использовать Попечители Linux. Он вдохновлен доверенными лицами Novell давным-давно, и он (имхо) превосходит все, что я видел.

Не вдаваясь в подробности, вам нужно поддерживать один файл конфигурации; При попытке использовать списки контроля доступа и тому подобное, ваша видимость не так хороша, как вам приходится запрашивать файлы по отдельности.

С опекунами Linux вы также можете выбрать И с разрешениями Unix или игнорировать их все вместе.

Единственным недостатком является то, что это модуль ядра (что само по себе неплохо), но вам, вероятно, потребуется перекомпилировать ядро ​​с соответствующей поддержкой (согласно документации опекунов). Это снова не проблема, но если у вас есть поддержка, например, со стороны Red Hat, то перекомпиляция / изменение ядра не будет вариантом.

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

Я бы сделал LWO, если ... у вас уже есть Windows AD и многие потенциальные машины, которым требуются разрешения таким образом.

Может, пора использовать централизованную систему вроде LDAP? Я бы сказал, что FreeIPA: очень гибкий, приятный пользовательский интерфейс, множество функций. И это просто работает.