Предоставление пользователя прочитало полномочия везде (Linux)

Не могло бы на самом деле быть ничего неправильно с Вашей установкой. За исключением того, что Вы пытаетесь отправить письма от динамично выделенного IP-адреса, например, с коммутируемой учетной записью. Много MTAs (почтовые серверы) отклоняют письма от клиента из диапазона IP, который используется для коммутируемых учетных записей, потому что большинство писем спама сегодня, вероятно, поставляется захваченными потребительскими компьютерами.

4
задан 7 October 2010 в 16:17
8 ответов

Вы смешиваете две команды:

  • показанный это используется для изменения владельца файла. Exemple: chown root:adm /etc/passwd

  • chmod, который используется для изменения разрешения файла. Exemple: chmod g+r myfile

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

Какова Ваша цель?

4
ответ дан 3 December 2019 в 02:18
  • 1
    Точно! Я не хочу, чтобы резервный пользователь владел каждым файлом, и при этом я не хочу, чтобы у каждого пользователя был доступ для чтения везде. По некоторым причинам другие не могли понять это. Я понимаю различие между показанным и chmod. Я просто хочу, чтобы резервный пользователь так или иначе смог считать каждый файл, таким образом, он может сделать свое задание. –  Jason Swett 7 October 2010 в 16:12
  • 2
    Некоторые файлы не должны быть читаемыми никакими другими пользователями, чем их владелец (ssh закрытый ключ для exemple). Если Вы хотите скопировать свою систему, можно или считать неструктурированный диск (но, вероятно, придется восстановить целый диск для получения только 1 файла), или сделайте резервное копирование как корень. –  Benoit 7 October 2010 в 16:23
  • 3
    Если некоторые файлы не должны быть читаемыми никем кроме их владельцев, как резервное копирование как корень лучше, чем создание пользователя, который прочитал полномочия везде? Резервное копирование как корень, кажется, нарушение принципа наименьшего количества полномочия, так как резервный пользователь не должен записать или выполнить что-либо, просто читайте. –  Jason Swett 7 October 2010 в 16:33
  • 4
    SSH для exemple не работает при изменении разрешения на файлах ключей. Вот почему необходимо скопировать ключи как корень (или их владелец). –  Benoit 7 October 2010 в 17:04

Правильный способ сделать это не путем изменения полномочий файла. Необходимо использовать sudo и/или исполняемые файлы setuid.

4
ответ дан 3 December 2019 в 02:18
  • 1
    Все операции, выполненные моим резервным пользователем, являются предконсервированными, таким образом, у меня нет опции использования sudo. –  Jason Swett 7 October 2010 в 16:30

chmod g+r myfile

g представляет группу файла (администраторы).

r представляет разрешение чтения.

  • представляет то, что разрешение добавляется.
1
ответ дан 3 December 2019 в 02:18

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

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

Полностью нормально создать резервную копию как корень.

Bart.

1
ответ дан 3 December 2019 в 02:18

файл chmod 0444/. для простоты используйте это: http://permissions-calculator.org/

0
ответ дан 3 December 2019 в 02:18

В Linux, если вы используете файловую систему с поддержкой ACL (ext3, ReiserFS, ZFS, я думаю), вы можете установить право чтения и обхода каталогов для вашего пользователя-оператора резервного копирования.

Допустим, вы хотите сделать резервную копию / home

  1. Ваш раздел должен быть смонтирован с параметром «acl» (вы можете сделать это с помощью mount -o remount, acl / home )
  2. Установить инструменты acl (setfacl и getfacl)
  3. setfacl -R -mu: "Backup User": rx / home

Если вы хотите убедиться, что новые файлы и каталоги будут иметь соответствующие права, установите ACL по умолчанию:

  1. setfacl -R -md: u: "Backup User": rx / home

Очевидно, вы можете сделать это более тонко (например, если вы не хотите создавать резервные копии ключей gnupg или ssh, - который в любом случае должен быть защищен паролем)

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

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

или делать гадости от имени root.

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

или делать гадости от имени root.

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

18
ответ дан 3 December 2019 в 02:18

-привилегии будут краткими для разрешений (или привилегий) --

Какая разница, что "они" скажут "должны" / "не должны", не все из нас управляют ПК уровня АНБ, а некоторые из нас (например, чувак в ОП) могут извлечь выгоду из небольшой политики "все-все-все-читай":

У одного из моих коллег есть коробка linux, в которой есть все, что можно прочитать (кроме корневой папки и папки lost+found), так что любой пользователь (например, я могу найти аккуратные вещи в своей папке /home/notme или в папке /etc/)

sudo chmod -R +r /
sudo chmod -R 700 /root
sudo chmod -R 700 /lost+found

ПРИМЕЧАНИЕ: папка /root, вероятно, принадлежит root:root (корневой пользователь и корневая группа), но мы сказали корневой группе, что никаких приватов нет. .. Что ж, это нормально, потому что пользователь root все еще имеет приватный доступ, так что, что самое главное, если ваш корень прав? В основном, если ваш пользователь root, и вы пытаетесь попасть в папку/файл, в котором написано, что у вас есть полный privs, но у вас нет privs... кто победит? Ну, приватные файлы пользователей root говорят, что вы можете попасть внутрь, вот что важно (приватные файлы корневой группы даже не просматриваются)... Также, так как ваш пользователь root, вы можете изменить все это

.
-3
ответ дан 3 December 2019 в 02:18

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

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

Это не обязательно позволит вам создать резервную копию каждого файла, но позволит вам создать резервную копию каждого файла, который пользователи не устанавливают как частные. Файлы X00 не будут копироваться.

Одним из недостатков этого подхода является то, что вы должны идти в ногу с новыми группами по мере их создания. Также для этого требуется, если вы хотите сделать резервную копию домашних каталогов, чтобы вы установили, по крайней мере, права на выполнение для / home (для группы).

Как кто-то еще упомянул, это может нарушить ssh с ключами в зависимости от вашей реализации.

0
ответ дан 3 December 2019 в 02:18

Теги

Похожие вопросы