Linux & NFS: атомарное сравнение и обмен владением файлами
Мой ИТ-отдел сделал ошибку и разбил каждый файл в файловой системе на root:OurGroup, Затем их автоматическое резервное копирование (т.е. .snapshop) система создала снимок, поэтому у нас больше нет ссылок на то, какие разрешения были раньше.
Я пытаюсь работать с ними, чтобы создать сценарий, в котором будет установлен бит set-uid и он будет принадлежать пользователю root, который пользователи могут вызывать для повторного выбора файлов / каталогов обратно по мере необходимости.
Я ожидаю, что им не понадобится сценарий, который будет им просто что-то назначать, но вместо этого он может захотеть создать нового пользователя, назначить ему все, а затем попросить пользователей вызвать сценарий, которому будут принадлежать файлы chown. им, если он принадлежит этому другому пользователю.
Тем не менее, чтобы избежать условий гонки, я хочу найти способ ограничить выбор, если файл принадлежит только этим пользователям. Здесь есть условие гонки: если я делаю это в двух отдельных вызовах и два пользователя одновременно запускают этот сценарий для файла, это может вызвать конфликты. Вместо этого я хотел бы "сменить владельца, если владелец является пользователем" за один вызов, вместо "если владелец является пользователем", а затем "сменить владельца"
Существует ли атомарный примитив сравнения и обмена для владения файлами?
2 ответа
Тем не менее, чтобы избежать условий гонки, я хочу найти способ ограничить выбор, если файл принадлежит только этим пользователям. Здесь есть условие гонки: если я делаю это в двух отдельных вызовах и два пользователя одновременно запускают этот сценарий для файла, это может вызвать конфликты. Вместо этого я хотел бы "сменить владельца, если владелец является пользователем" за один вызов, вместо "если владелец является пользователем", а затем "сменить владельца"
Вы, кажется, подразумеваете, что как только право собственности на файл изменилось с root:OurGroup на что-то более вменяемое, такое как user1:department-name второй пользователь не может снова сменить владельца user1:department-name в user2:some-team,
Это не совсем проблема, хотя...
Проблема не в том, что два пользователя одновременно запускают или выполняют скрипт chown Команды вскоре после другой или одновременно, проблема гораздо сложнее:
Как вы собираетесь разрешать конфликты, когда несколько пользователей претендуют на владение одним и тем же файлом или каталогом?
Представьте, что первый пользователь, который запускает ваш скрипт, просто выбирает каждый файл и каталог...
Ваша проблема решена, когда все файлы переходят из root:OurGroup как UID:GID для user1:department-name и будет ли право собственности тогда восстановлено правильно?
И должен ли последующий запуск от user2, который только хочет владеть <path>/Department-Name/User1's files/* быть отказано?
Как упомянул @Lacek, лучше всего использовать более старую резервную копию в качестве шаблона для владения файлами, которые все еще существуют в текущей файловой системе, и фокусироваться только на вновь созданных файлах, которые не существуют в резервной копии. (Подход первого уровня дает этим файлам того же владельца, что и вложенный каталог).
chmod так же хорошо как chown команда поддержки --reference флаг. Вы можете указать на существующий файл из вашей резервной копии и chown будет использовать владельца и группу этого ссылочного файла / каталога вместо того, чтобы указывать значения OWNER:GROUP напрямую, то есть что-то в строках:
cd /old-backup-of-nfs-share/
find . -exec chmod -v --reference='{}' /current-nfs-mount/'{}' \;
В оболочке такого нет, но вы можете эмулировать flock (см. эту запись Stackoverflow)
Однако, как указал Свен, вам придется использовать sudo для разбивки файлов, так как биты setuid игнорируются в сценариях.
Также может быть лучше восстановить более раннюю резервную копию и проверить там разрешения. Вероятно, он будет охватывать большинство файлов, с которыми вы хотите работать, и кажется, что это более точный способ восстановления прав собственности, чем предоставление пользователям догадок.