Сохраняет ли 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.