Вопросы Теги

Дальнейшие вопросы о - соединяют каналом для находки

[1126804] Если я вас правильно понял, то в /dev/sdb есть какая-то файловая система, которую вы смонтировали. Здесь важны разрешения [1127355]в файловой системе [1127356], которая находится в /dev/sdb, разрешения /dev/sdb совершенно не относятся к вашему вопросу. За исключением того, что с разрешениями 0666 любой может обойти механизмы контроля доступа к этой файловой системе и получить произвольный доступ к содержимому устройства, но это другая проблема.

Если вы хотите ограничить доступ к файлам внутри файловой системы, то вы должны назначить файлам соответствующие права собственности и разрешения (начиная с корня этой файловой системы). Для файловых систем типа FAT mount(8) позволяет установить права собственности и доступа для всех файлов внутри файловой системы. Если вы хотите выставить все дерево только для определенных пользователей и скрыть его от всех остальных, то смонтируйте его где-нибудь, к чему имеют доступ только эти пользователи. Но обратите внимание, что любой пользователь может увидеть, что что-то монтируется (mount(8) или df(1) покажут это).

chroot(1) вам вообще не поможет.[1126809].

1
13.04.2017, 15:36
2 ответа

Чтобы избежать путаницы, вы, вероятно, должны подумать о прототипе Найти (1) Как это: 

find [-H] [-L] [-P] [-D debugopts] [-Olevel] [dir...] [expression]

Найти (1) находит файлы в dir . Выражение - это логическое выражение, сформированное из тестов, которые применяются к найденным файлам. -Path , -name , --тип являются примерами таких испытаний.

  1. Выше в основном говорится -Path не устанавливается dir , но это аргумент взят по отношению к dir .

  2. говорит -Path '* SRC *' совпадает как ./ SRC / FOO / BAR / TEST.C и . / . / Foo / src / bar / test. C , но не ./ FOO / BAR / TEST.C .

  3. говорит * - это подстановочный знак, и он соответствует каталогам. Он также говорит, что вы не должны спутать его с * из мира DOS / Windows, где вам нужно написать *. * , чтобы соответствовать файлам с «расширениями».

Или, по крайней мере, это мое понимание этого.

2
27.01.2020, 23:16

Удаляется любой файл в стандартной файловой системе UNIX, для которого ссылочный счетчик (например, сумма количества жестких ссылок и число открытых дескрипторов файлов *) достигает 0. Однако в современных UNIX-системах системный вызов rmdir удаляет пустой каталог за одну операцию, а не . и .. один за другим.

Однако в исторических системах UNIX этот системный вызов не существовал. Вместо этого команда rmdir представляла собой программу setuid ( исходный код можно найти здесь ), которая проверяла, что каталог пуст (кроме специальных записей), а затем удаляла .. и . , в этом порядке, а затем удалил сам каталог, все с unlink системный вызов, который только root было разрешено использовать в каталогах (следовательно, почему команда была setuid). Таким образом, в этих системах число ссылок каталога будет на мгновение равно 1 после . был удален, но до удаления каталога из родительского каталога он будет равен 0.

Команда rm , кстати, не позволила даже root удалить каталоги. И rm -r вызовет команду rmdir для удаления каталогов после удаления их содержимого.

В этих исторических системах неправильное использование вызова unlink из программы, выполняющейся от имени root, переход в состояние гонки с помощью rmdir или mv или создание файла в процессе, текущий каталог которого был удален (современные системы предотвращают это), может привести к зависанию файлов или каталогов, которые имеют число жестких ссылок выше 0, но не существуют в дереве каталогов. Это состояние было обнаружено dcheck и по-прежнему является одной из проверок в fsck , поскольку оно остается физически возможным в большинстве файловых систем.

Файловые системы, кстати, не требуются для реализации каталогов (включая . и .. ) как обычные файлы с аппаратными ссылками. В этих файловых системах количество жестких ссылок каталога всегда будет отображаться как 0 (но, конечно, его существование в родительском каталоге соответствует «количеству ссылок» 1).

Поведение удаленного каталога (например, при проверке процессом, который уже открыл его или имеет его в качестве текущего каталога) и точное значение «счетчика ссылки» каталога не указаны. Например, в Mac OS X он сообщает о количестве жестких ссылок 2 , даже если у него нет реальных жестких ссылок. Даже если . и .. не отображаются в списке, каталог можно открыть и вызвать stat с именем . или .. . В Linux число ссылок равно 0, но равно . и .. также работает.

Mac OS X также сообщает количество всех файлов в каталоге в качестве количества ссылок вместо количества подкаталогов. Но это 2, даже когда . и .. исчезли.

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

-121--39847-

Вы можете использовать debug для дампа переменной: 

- name: this command prints FAILED when it fails
  command: /usr/bin/example-command -x -y -z
  register: command_result
  failed_when: "'FAILED' in command_result.stderr"
- name: dump command_result
  debug: var=command_result

Это будет выводиться что-то вроде: 

TASK: [dump command_result] **************************************************************
ok: [hostname] => {
    "command_result": {
        "changed": false,
        "cmd": "/usr/bin/example-command -x -y -z",
        "delta": "0:00:00.018233",
        "end": "2015-05-07 09:33:08.444674",
        "invocation": {
            "module_args": "/usr/bin/example-command -x -y -z",
            "module_name": "command"
        },
        "rc": 0,
        "start": "2015-05-07 09:33:08.426441",
        "stderr": "",
        "stdout": "whatever",
        "stdout_lines": [
            "whatever"
        ],
        "warnings": []
    }
}
-121--202580-

  1. Да, «начальный путь» означает одно из отображаемых имен каталогов рядом с началом команды find , после параметров, но до выражения. Я интерпретирую вопрос, с которым вы связали, как предполагающий, что эта ОП путался по поводу разницы между 

     находкой/и т.д....

    и 

     найти -path/etc...

    • "Оно относится к комбинации начального пути и относительный путь в настоящее время исследованного объекта. «

      я предполагаю, что автор того ответа воображает это имеется каталог с именем tools/crowbar , который содержит файлы пить , пищу , глупость и мудрость . Если вы говорите 

      , найдите tools/crowbar -path «* bar/foo *»

      он найдет инструменты/ворон бар/foo d и инструменты/ворон бар/foo лишество , но не два других.

  2. Я согласен с lcd047. Другими словами, если у вас есть структура каталогов, как 

    .
├───cat
│ собака ├───
│ │ └─── конура
│ └─── tac
│ └─── src
├───dest
├───original
│ рецепт ├───
│ └─── src
└───src

    then

     find. -path «*/src/*»

    найдет вещи во всех трех папках src (и во всех их подкаталогах) без сообщения о вещах в кошке , кошке/собаке , кошке/собаке/питомнике , cat/tac , dest , original или original/recipe .

  3. Это помогает читать целые абзацы, а не только черешневые фрагменты предложения и ожидать, что они будут иметь смысл в изоляции. Обсуждение теста - путь в find (1) говорит,

    -path образцов

      Имя файла совпадает с именем оболочки образца образцов . Метасимволы не обрабатывают '/' или '. 'специально; так, например, 
           найти. -path. «/sr * sc »
      напечатает запись для каталога с именем ' ./src/misc ' (если существует)....

    OK, когда вы видите «имя файла», «шаблон оболочки», и «метасимволы» в одной строке, ожидается, что вы подумаете о совпадении образца оболочки/ расширение имени пути, которое имеет специальные символы образца * , ? и [ ... ]. («Metacharacter» в основном является словом $10 для «специального символа»).А потом он идет и показывает вам пример с * в нем! Так что вы должны уметь понять, о чем речь.

    Так что же это говорит? Посмотрите на пример: sr * sc соответствует src/misc . Это отличие от расширения пути в оболочке, где, как правило, необходимо использовать что-то вроде sr * / * sc для соответствия src/misc . И, нет, это не относится только к * ; -тракт «sr???? sc» и -тракт «sr [cim/] [cim/] [cim/] [cim/] [cim/] sc» работать в одном и том же пути.

    И они не спешат упоминать, что -path «* sr * sc» будет соответствовать не только src/misc , но и .src/misc и src/.misc ; несмотря на то, что * sr */* sc обычно не совпадает с ними (в оболочке) потому что, в расширении пути оболочки, * обычно не совпадает с именами, начинающимися с . .

3
27.01.2020, 23:16

Теги

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