объяснение на показанном (1) спецификация POSIX

Несколько мыслей о создании сценария:

• Использование manpath для определения местоположения страниц. Если я добавлю /home/graeme/.cabal/bin в мой PATH , manpath (и man ) найдут страницы-мужчины в /home/graeme/.cabal/share/man .

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

• Сохранение отформатированных страниц в файле tempfile позволит избежать многократных распаковок и значительно ускорить процесс.

Далее (с помощью bash и GNU find):

#!/bin/bash

set -f; IFS=:
trap 'rm -f "$temp"' EXIT
temp=$(mktemp --tmpdir search_man.XXXXXXXXXX)

while IFS= read -rd '' file; do
  man "$file" >"$temp" 2>/dev/null

  unset fail
  for arg; do
    if ! grep -Fq -- "$arg" "$temp"; then
      fail=true
      break
    fi
  done

  if [ -z "$fail" ]; then
    file=${file##*/}
    printf '%s\n' "${file%.gz}"
  fi
done < <(find $(manpath) -type d ! -name 'man*' -prune -o -type f -print0)

Try

rsync --protect-args --size-only -avzPe ssh  "/mnt/xlses/split/v2/name with space/ "root@myserver.com:/mnt/xlses/split/v2/name with space"

From man rsync :

-s, --protect-args

Этот параметр отправляет все имена файлов и большинство параметров в удаленный rsync без разрешения удаленной оболочки Это означает, что места не разделяются по именам, а любые специальные символы без подстановочных знаков не переводятся (например, ~, $,;, & и т.д.). Подстановочные символы расширяются на удаленном хосте с помощью rsync (вместо оболочки, выполняющей это действие). [...]

Допущения 1: правила определения того, успешно ли chown проверяет целевого пользователя и части группы независимо, т.е. они имеют вид user _ condition (target_uid, other_environment_parameters) & & group_condition (target_gid, other_environment_parameters) .

Предположение 2: chown (файл, -1, -1) успешно выполнено.

Допущения 3: правила определения успешности chown не зависят от того, к какой группе в данный момент принадлежит файл.

В случае успеха chown (файл, uid, gid) , chown (файл, -1, gid) & & chown (файл, uid, -1) .

Я не знаю вариант Unix, который нарушил бы ни одно из этих предположений, они кажутся довольно безопасными.

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

Случай, когда предположение, 3 может быть неправильным, относится к системе, в которой процесс может получить возможность изменять владельцев файлов, но только если у него есть разрешение на запись в файл. Хотя я немного реалистичен, я не знаю ни одной системы, где это происходит. Затем chgrp в группу из процесса, который не работает как root или как пользователь, владеющий файлом, может сделать файл отключенным для более позднего chown .

Для рекурсивного вызова:существуют граничные случаи, когда полный проход chgrp , за которым следует полный проход chown , может завершиться неудачей, когда один проход будет успешным. Это не очень убедительный аргумент, потому что он включает в себя каталоги, которые владелец не имеет разрешения на прохождение, и приложение, которое хотело бы защитить от всех таких случаев, в любом случае должно быть проверено с разрешениями. Тем не менее он технически соответствует условию этого обоснования. Предположим, что запущенный процесс имеет эффективного пользователя alice , эффективного персонала группы и возможность произвольного изменения владельцев файлов (не только для их передачи; несколько вариантов unix имеют такую возможность, хотя она редко предоставляется некорневым процессам).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

Подсистема Microsoft Interix Unix (сейчас исключена) для своего ядра NT немного по-другому обрабатывала права пользователей и групп, чем некоторые другие:

Информация о пользователях и группах хранится в базе данных Security Access . И пользователи, и группы хранятся в одной базе данных, но имена групп и пользователей должны быть уникальными; ни одна группа не может иметь имя пользователя и наоборот. (Эта база данных заменяет файлы / etc / passwd и / etc / groups в UNIX.) Пользователи и группы создаются с использованием соответствующей методологии Windows (Диспетчер пользователей, Пользователи и компьютеры Active Directory или Локальные пользователи и группы) или с помощью команды Win32 net user . (Примеры сценариев оболочки для создания и удаления пользователей включены в каталог / usr / examples / admin .) Пользователи могут принадлежать ко многим группам.

Вот некоторые более конкретные выдержки из руководства:

В Windows пользователь или группа могут владеть объектом. Это отличается от UNIX, в которой только пользователь владеет объектом.

Windows идентифицирует всех пользователей и группы внутри с помощью идентификатора безопасности (SID) . Алгоритм хеширования генерирует уникальные значения SID; у двух пользователей или групп не будет одинаковых SID.

Пользователи и группы, у которых есть разрешение на доступ к объекту, идентифицируются их SID. Все объекты, которые могут быть защищены Windows, имеют дискреционный список управления доступом (DACL), который состоит из отдельных записей, называемых записями управления доступом (ACE).ACE включает в себя две важные части информации: идентификатор безопасности пользователя или группы и описание степени доступа отдельного пользователя или группы к объекту.

CHGRP

... Изменить идентификатор группы для файла ... пользователь, вызывающий chgrp (1), должен принадлежать к указанной группе и быть владельцем файла или иметь соответствующие привилегии.

CHOWN

... Операнды владельца и группы необязательны; однако одно необходимо указать. Если указан групповой операнд, ему должен предшествовать двоеточие (:).

Владелец может быть указан либо числовым идентификатором пользователя, либо именем пользователя. Если имя пользователя также является числовым идентификатором пользователя, операнд используется как имя пользователя. Группа может быть числовым идентификатором группы или именем группы. Если имя группы также является числовым идентификатором группы, операнд используется как имя группы.

По соображениям безопасности право собственности на файл может быть изменено только процессом с соответствующими привилегиями.

Насколько я читал, это означает, что если ваша учетная запись пользователя принадлежит к группе Windows с достаточными привилегиями для изменения прав доступа к файлу, принадлежащему этой группе, то можно эффективно chgrp этот файл вне контроль вашей учетной записи. Это означает меньший контроль, чем при использовании параметров chown и явных user: group . В этом контексте без возможности объявления user: и : group вы никогда не смогли бы достичь тех же результатов, что и в противном случае.

Вот ссылка на подробный обзор того, как Interix взаимодействует с Windows ACL, с акцентом на то, как эти знания могут применяться к файловым системам Samba в других вариантах Unix.

Вот ссылка на теперь устаревший документ Solaris, описывающий настраиваемый rstchown , который ...

Указывает, соответствует ли семантика POSIX для chown (2) Системный вызов действует ...

Очевидно, если для параметра установлено значение 0 ...

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

Такая опция не отменяет соответствие Solaris POSIX . Тот факт, что это вариант вообще, квалифицирует его как совместимый :

Хотя все реализации, соответствующие POSIX.1-2008, поддерживают все функции, описанные ниже, может быть системные или файловые системные процедуры конфигурации, которые могут удалить или изменить любую или все эти функции. Такие конфигурации не следует выполнять , если требуется строгое соответствие.

Следующие символические константы должны быть определены со значением, отличным от -1 . Если константа определена с нулевым значением, приложения должны использовать функции sysconf () , pathconf () или fpathconf () . или утилитой getconf , чтобы определить, какие функции присутствуют в системе в то время или для конкретного рассматриваемого пути.

_POSIX_CHOWN_RESTRICTED

Использование chown () ограничено процессом с соответствующими правами и изменением идентификатора группы файла только на эффективный идентификатор группы процесса или один из его дополнительных идентификаторов группы.

Системная функция chown () - документированный системный вызов, выполняемый утилитами оболочки chown и chgrp , - указывается для терпят неудачу по многим причинам.Среди них:

EACCES Запрещено разрешение на поиск для компонента префикса пути.

ELOOP Цикл существует в символических ссылках, обнаруженных во время разрешения аргумента пути.

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

Однако поведение при предоставлении прав на изменение разрешений пользователям без полномочий root никогда не было уникальным для Solaris. В этом сообщении на форуме есть очень превосходное - хотя и несколько устаревшее - освещение разрешений файлов Unix, в котором автор заявляет:

Первоначально Unix позволяла владельцу файла выдавать файл. Владелец файла может сменить владельца на кого-то другого. Пользователь без полномочий root не мог отменить эту операцию ... BSD [позже] удалил chown у пользователей без полномочий root ... [отчасти потому, что ] ... в нем реализованы дисковые квоты, которые могут ограничивать объем дискового пространства, которое пользователь может иметь в файловой системе ... Непослушные пользователи могут отдавать большие файлы, чтобы незаметно обходить квоты.

Сегодня нелегко сказать, может ли не root перехватить файл. Многие версии Unix допускают оба поведения ...

Еще одно хорошее - и более свежее - сообщение в списке рассылки цитирует это и продолжает:

По умолчанию для большинства ОС для chown можно использовать только root. И есть консенсус в том, что так следует оставаться по соображениям безопасности.Если пользователь без полномочий root меняет владельца файла и установлен любой бит выполнения, биты SUID и SGID должны быть очищены. Это может произойти, а может и не произойти с корнем .

Я думаю, что последний абзац хорошо об этом говорит.

В этой статье также упоминается CAP_CHOWN для управления этим средством в Linux (это должно влиять только на поведение POSIX_CHOWN_RESTRICTED ) . Также есть возможность CAP_FOWNER , которая немного отличается по поведению.

И как вы указываете в 2003 году :

Обратите внимание, что, по крайней мере, в HPUX вы можете изменить владельца ваших файлов (на root например) , даже если вы не являетесь привилегированным пользователем ...

... который зависит от параметра конфигурации setprivgroup .

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

В этом сценарии chown , затем chgrp завершится ошибкой, поскольку у пользователя больше не будет разрешений на изменение прав доступа к этому файлу, тогда как chown user: group - поэтому пока группа входит в число собственных пользователей - будет успешно.

Существует , вероятно, множество других нишевых ситуаций, которые могут привести к аналогичному результату, которые могут включать каталог липкие и / или биты setgid , файловую систему и / или списки управления доступом, зависящие от реализации. Эта ветка , например, интересна.Бесчисленные перестановки выходят далеко за рамки моего собственного слабого понимания - вот почему этот ответ является вики-сайтом. Если вы читаете это, вы считаете, что его стоит улучшить, и вы верите, что знаете, как - , пожалуйста, сделайте .

Здесь также имеется обширная документация о различных возможных эффектах прав доступа к файлам, обхода дерева и символических ссылок, которые могут вызвать аналогичный сбой в отношении приложений -R ecursive chown . :

Из POSIX XRAT заголовки разделов Третий и Четвертый домены :

Обычно пользователи, указывающие параметр для обхода файловой иерархии, хотят работать с единственная физическая иерархия и, следовательно, символические ссылки, которые могут ссылаться на файлы вне иерархии, игнорируются. Например, команда chown owner file отличается от той же команды с указанным параметром -R. В этом примере поведение команды chown владелец файл описано здесь, а поведение команды chown -R owner file описано в третьем и четвертые домены.

... Существует проблема безопасности, связанная с логическим обходом по умолчанию. Исторически команда chown -R user file была безопасной для суперпользователя, потому что биты setuid и setgid были потеряны при смене владельца файла. Если бы обход был логичным, смена владельца уже не была бы безопасной, потому что пользователь мог бы вставить символическую ссылку, указывающую на любой файл в дереве.Опять же, это потребовало бы добавления опции к командам, выполняющим обход иерархии, чтобы не косвенно через символические ссылки, а исторические сценарии, выполняющие рекурсивные обходы, мгновенно стали бы проблемами безопасности. Хотя это в основном проблема для системных администраторов, желательно не устанавливать разные значения по умолчанию для разных классов пользователей.

...

В 4.3 BSD, chgrp во время обхода дерева изменяет группу символической ссылки, а не цель. Символические ссылки в BSD 4.4 не имели владельца, группы, режима или других стандартных атрибутов файлов системы UNIX.

И на самой странице POSIX chgrp есть то, что указывает на возможное неполное экурсивное действие -R или, по крайней мере, на то, что использовал как :

Версии System V и BSD используют разные коды статуса выхода. Некоторые реализации использовали статус выхода как подсчет количества возникших ошибок; эта практика неприменима, поскольку она может выйти за пределы диапазона допустимых значений статуса выхода. Стандартные разработчики решили замаскировать их, указав только 0 и> 0 в качестве выходных значений.