Сохраняет ли tar разрешения при изменении идентификаторов пользователей?


20

Мне нужно сделать резервную копию некоторых данных с помощью опции «p» в команде tar. Проблема в том, что в месте, где я собираюсь восстановить эти данные, будут одни и те же пользователи, но у этих пользователей могут быть разные идентификаторы. Имеет ли это какое-то значение для tar или он правильно восстановит права доступа по имени пользователя?

Ответы:


9

tarЗаписывает разрешения на основе UID и GID, а не на связанной с ними строке. Таким образом, если UID на одном сервере был 3300 и он был связан с «bob», на новом сервере файл будет принадлежать пользователю с UID 3300.

Виртуально все (я хочу сказать все, но вы не можете быть на 100% уверены) в UNIX использует значения UID: GID, потому что это то, что на самом деле хранится на уровне файловой системы. Имя - это просто поиск в файле passwd, основные проверки выполняются с использованием числовых значений.


Ах, это не хорошо ... Я думаю, что в большинстве ситуаций это подходит. К сожалению, не для меня ... Спасибо, EightBitTony.
Мариус

3
Скорее всего, вы имеете в виду GID (идентификатор группы), а не GUID (глобальный уникальный идентификатор).
CVN

6
GNU tar также сохраняет данные об именах пользователей / групп, потому что я могу увидеть их, если я перечислю архив на машине, у которой нет этих пользователей. Должен быть способ заставить это использовать это во время извлечения.
Роб Х

3
Этот ответ просто неверен. tar делает запись имен владельцев.
Штеффен Хейл

55

Подведение итогов предыдущих ответов и добавление важной информации:

  • При создании архивов, tarвсегда будет сохранять файлы идентификатор пользователя и группы, если не указано иное с --owner=NAME, --group=NAME. Но все равно всегда будет пользователь и группа, связанные с каждым файлом.

  • GNU деготь, и , возможно , другие версии tar, также хранить пользовательские и групповые имена , если --numeric-ownerне используются. bsdtar также хранит имена пользователей и групп по умолчанию, но поддержка --numeric-ownerопции при создании появилась только в bsdtar 3.0 (обратите внимание, что bsdtar поддерживает опцию при извлечении гораздо дольше).

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

  • При извлечении в качестве корня , tarпо умолчанию будет восстановить владение извлекаемых файлов, если --no-same-owner не используются, что даст право собственности на корень сам.

  • В GNU дегтя, bsdtar, и , возможно , других версий tar, восстановлено право собственности осуществляется пользователем (и группы) имя , если эта информация находится в архиве и есть соответствующий пользователь в системе назначения. В противном случае он восстанавливается по ID. Если --numeric-ownerопция включена, имена пользователей и групп игнорируются.

  • Разрешения и временные метки также сохраняются в архив и восстанавливаются по умолчанию, если не используются параметры --no-same-permissionsи / или --touchне используются. Когда извлечено пользователем, пользователь umaskбудет вычтен из разрешений , если --same-permissionsне используются.

  • --preserve-permissionsи --same-permissionsявляются псевдонимами, и имеют ту же функциональность, что и-p

Надеюсь, это поможет прояснить проблему! :)


3
Отличный ответ; Отвечает на этот вопрос, а также на любой другой вопрос, который может возникнуть по этому вопросу.
user1107893

Следует отметить, что только последние версии GNU tarпозволяют указывать произвольные имена в --ownerили --group, в прошлом tarвыполнял произвольный поиск на текущем компьютере /etc/passwdи отказывался запускаться, если не было совпадения.
Matteo Italia

Что произойдет, если вы создадите архив с указанным именем, --ownerно также добавленный в --numeric-ownerфлаг? Как tar справляется с этими конкурирующими требованиями?
CMCDragonkai

@CMCDragonkai: --ownerи --numeric-ownerне являются взаимоисключающими, и служат очень разным целям: --owner=USERNAMEбудут перезаписывать файлы и владельцев dirs при архивации файлов, но --numeric-ownerпросто не будут хранить имя пользователя, только его числовой идентификатор.
МестреЛион

4

Используйте параметр --same-owner для GNU tar. См. Http://www.gnu.org/software/tar/manual/html_section/Attributes.html.


Это задокументировано как значение по умолчанию для суперпользователей и, по-видимому, отвечает на вопрос ОП не так, как принятый ответ. (Ссылка говорит, что когда GNU tar восстанавливается с использованием --same-owner, он сначала ищет имена в / etc / passwd.) Единственная нерешенная проблема заключается в том, реализует ли версия OP tar OPs --same-owner.
Майк Шеррилл 'Cat Recall'

ОП использует какой-то дистрибутив Linux, так что даже лучше, чем шанс использовать GNU tar, methinks. Отправившись в документации это является возможным в то время как общепринятый ответ указывает , что это не так ...
Colin «т Харт

@Catcall - извините, я принял ответ, даже не имея возможности проверить его. Иногда я просто слепо доверяю людям. Тем не менее, человек, который ответил, был довольно прав, так как я не восстанавливал с "--same-owner", а затем вы добавили к ответу. Жаль, что я не могу принять оба. Я использую Debian Squeeze, который действительно поддерживает "--same-owner". Спасибо за чаевые.
Мариус

@Marius: Я уверен, что вы можете изменить принятый ответ, когда захотите. (Я просто укажу, что я не дал никаких ответов на этот вопрос, только комментарии. У меня нет ни одного представителя.)
Майк Шеррилл 'Cat Recall'

4

Если вы пытаетесь передавать файлы между двумя системами, rsync по умолчанию установит права доступа по имени пользователя вместо uid, просматривая имена пользователей с обеих сторон. Только если пользователь не существует в одной из систем, он скопирует его с помощью uid, если вы не укажете обратное.


Это не дает прямого ответа на вопрос ФП, но любой, кто задает вопрос ФП, должен тоже это узнать.
Майк Шеррилл 'Cat Recall'
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.