Каково преимущество синхронизации UID/GID через машины Linux?

технический долг

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

сетевые файловые системы

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

Соображения, касающиеся сетевой файловой системы, - это, пожалуй, самый серьезный случай для попытки сохранить ваши сопоставления UID / GID синхронизированными, потому что вы обычно можете выбросить это «достигнутое в противном случае», о котором вы упомянули, из окна в тот момент, когда они входят в изображение. Конечно, у вас может не быть сетевых файловых систем, совместно используемых этими хостами прямо сейчас ... но как насчет будущего? Можете ли вы честно сказать, что никогда не будет варианта использования сетевой файловой системы между вашими текущими хостами или хостами, которые будут созданы в будущем? Было бы не очень дальновидно предполагать иное.

Предположим, что / home является сетевой файловой системой, совместно используемой между host1 и host2 в следующих примерах.

• ] Несогласные разрешения : / home / user1 принадлежат разным пользователям в каждой системе. Это не позволяет пользователю постоянно получать доступ или изменять свой домашний каталог в разных системах.
• chown wars : It ' s очень часто пользователи отправляют заявку с просьбой зафиксировать права доступа к домашнему каталогу в конкретной системе. Исправление этой проблемы на host2 нарушает разрешения на host1 . Иногда может потребоваться несколько таких билетов, прежде чем кто-то отступит и поймет, что идет перетягивание каната. Единственное решение - исправить несовпадающие сопоставления идентификаторов. Это приводит к ...
• аду ребалансировки UID / GID : Сложность исправления идентификаторов позже возрастает экспоненциально из-за количества повторных применений, задействованных для исправления одного пользователя на нескольких машинах. ( user1 имеет идентификатор user2 , но user2 имеет идентификатор user17 ... и это ' s всего лишь первая система в кластере) Чем дольше вы ждете, чтобы исправить проблему, тем сложнее могут стать эти цепочки, часто требующие простоя приложений на нескольких серверах для правильной синхронизации.
• Проблемы безопасности : user2 на host2 имеет тот же UID, что и user1 на host1 , что позволяет им писать на / home / user1 на host2 без ведома user1 . Затем эти изменения оцениваются на host1 с разрешениями user1 . Что возможно могло пойти не так? (если user1 является пользователем приложения, кто-то из разработчиков обнаружит, что оно доступно для записи, и внесет изменения . Это проверенный временем факт. )

Существуют и другие сценарии, и это лишь примеры наиболее распространенных.

имена не всегда являются опцией.

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

Пример: pam_succeed_if позволяет использовать поля пользователя ], uid и gid ... явно отсутствует опция "group". Если бы вы оказались в положении, когда несколько систем должны были реализовать какую-либо форму ограничения доступа на основе групп, у вас было бы n различных вариантов конфигураций PAM. (или, по крайней мере, один GID, с которым вы должны избегать коллизий)

централизованное управление

Ответ natxo довольно хорошо охватывает это.