Могут ли файлы являющиеся жесткой ссылкой на один объект иметь разные права доступа и владельца
Обновлено: 04.07.2024
Для разграничения действий над файлами определены три базовых права доступа (базовые разрешения):
соответствующие разрешению выполнять системные вызовы read, write и execve (точнее, системному вызову open с флагами O_RDONLY и O_WRONLY, но для простоты можно считать r — read, a w — write).
Каждое из базовых прав назначается на файл тому или иному пользователю или группе, разрешая соответствующую операцию.
В наследии классической UNIX определены только три субъекта, которым назначаются базовые права — пользователь-владелец (owner), группа-владелец (group owner) и все остальные (others). Совокупность их базовых прав называется режимом доступа (access mode) к файлу.
Базовое право может быть назначено r, w или х или отозвано —, поэтому в метаданных файла представляется одним битом, а для режима доступа требуется девять бит: по три бита прав на каждый из трех субъектов доступа. Компактно режим доступа может быть записан соответствующим числом в восьмеричной системе счисления rw-r—r— → 1101001002 → 6448.
Режим доступа к файлу
Доступ: (6644/-rw- r— r—) Uid: ( 1000/ john) Gid: ( 1000/ john)
-rw-r—r— 1 john john 677 марта 24 12:26 .profile
Если пользователь, осуществляющий операцию с файлом, является его владельцем, тогда используются только права владельца. В противном случае проверяется членство пользователя, осуществляющего операцию с файлом, в группе-владельцев файла, и тогда используются только права группы-владельцев.
В других случаях используются права для всех остальных, а для суперпользователя root вообще никакие проверки не осуществляются.
Использование режима доступа к файлу
[email protected]:~$ id john
uid=1000(john) gid=1000(john) группы=1000(john),4(adm),20(dialout),…,110(admin)
[email protected]:~$ ls -l README.*
-rw-r—r— 1 john admin 2471 ноя. 11 01:12 README.john
—w-r—r— 1 john admin 2471 ноя. 11 01:12 README.john.locked
-rw-r—r— 1 mike admin 776 ноя. 11 01:12 README.mike
-rw—-r— 1 bubble admin 171 ноя. 11 01:12 README.bubble
-rw-r—r— 1 stella admin 16 ноя. 11 01:12 README.stella
-rw-r—r— 1 troll admin 31 ноя. 11 01:12 README.troll
wc: README.admins: Отказано в доступе
wc: README.bubble: Отказано в доступе
24 177 2471 README, john
wc: README.john.locked: Отказано в доступе
wc: README.troll: Отказано в доступе
12 70 776 README.mike
1 1 16 README.stella
37 248 3263 итого
Режим доступа новых файлов
Назначается режим доступа файлов при их создании программой, создавшей файл, исходя из назначения файла, но с учетом пожеланий (точнее, нежеланий) пользователя.
Так, например, текстовые редакторы назначают создаваемым (текстовым) файлам права rw для всех субъектов, а компиляторы назначают создаваемым (программным) файлам права rwx для всех субъектов.
Пользователь может выразить свое нежелание назначать вновь создаваемым файлам те или иные права доступа для тех или иных субъектов, установив так называемую реверсивную (т. е. обратную, символизирующую нежелание) маску доступа при помощи встроенной команды интерпретатора umask.
Реверсивная маска доступа
[email protected]:~$ touch common.jnl
-rw-rw-r— 1 john john 0 ноя. 23 22:43 common. jnl
-rw-r—— 1 john john 0 ноя. 23 22:44 group, jnl
[email protected]:~$ touch private.jnl
-rw——— 1 john john 0 окт. 23 22:44 private.jnl
Изменять режим доступа разрешено непосредственному пользователю — владельцу файла, но не членам группы-владельцев, что иллюстрирует листинг ниже при помощи команды chmod.
Изменение режима доступа к файлу
[email protected]:~$ id john
utd=1000(john) gid=1000(john) группы=1000(john) ,4(adm),20(dialout),… ,20( admin)
[email protected]:~$ ls -l README.*
-rw-r-r— 1 john admin 2471 окт. 11 01:12 README.john
-rw-r-r— 1 mike admin 2471 окт. 11 01:12 README.mike
Семантика режима доступа разных типов файлов
Права доступа r, w, х для обычных файлов представляются чем-то интуитивно понятным, но для других типов файлов это не совсем так. Например, каталог содержит список имен файлов, поэтому право w для каталога — это право записи в этот список и право стирания из этого списка, что трансформируется в право удаления файлов из каталога и создания файлов в каталоге.
Аналогично, право r для каталога — это право просмотра списка имен его файлов. И наконец, право x для каталога является правом прохода в каталог, т. е. позволяет обращаться к файлам внутри каталога по их имени.
Права доступа к каталогу
drwxrwxr-x 2 john john 4096 окт. 12 00:37 folder/
[email protected]:~$ cp /etc/magic folder
[email protected]:~$ chmod u-w folder
dr-fxrwxr-x 2 john john 096 окт. 12 00:40 folder/
[email protected]:~$ cp /etc/localtime folder/
20318203 -rw-r—rw 1 john john 111 окт. 12 00:40 magic
[email protected]:~$ chmod u-r folder
d—xrwxr-x 2 john john 4096 окт. 12 00:40 folder/
ls: невозможно открыть каталог folder/: Отказано в доступе
[email protected]:~$ ls -li folder/magic
20318203 -rw-r—r— 1 john john 111 окт. 12 00:40 folder/magic
[email protected]:~$ chmod u-rw folder/
drw-rwxr-x 2 john john 4096 окт. 12 00:40 folder/
[email protected]:~$ cp /etc/localtime folder/
ls: невозможно получить доступ к folder/magic: Отказано в доступе
[email protected]:~$ chmod u=rwx folder/
drwxrwxr-x 2 john john 4096 окт. 12 00:40 folder/
-rw-r—r— 1 john john 111 окт. 12 00:40 magic
[email protected]:~/folder$ chmod a= magic
[email protected]:~/folder$ ls -l magic
————— 1 john john 111 окт. 12 00:40 magic
[email protected]:~/folder$ rm magic
Для жестких ссылок права доступа не существуют вовсе — они просто являются теми же правами, что и права целевого файла, в силу того что права доступа хранятся в метаданных.
Для символических ссылок семантика прав сохранена такой же, как и у жестких ссылок, с тем лишь различием, что права символических ссылок существуют отдельно от целевых файлов, но никогда не проверяются (symlink). Для изменения прав доступа самих символических ссылок даже не существует специальной команды — при использовании chmod со ссылкой всегда будут изменяться права целевого файла.
Права доступа ссылок
[email protected]:~$ ls -l README.john
-rwxr—r— 1 john john 2471 окт. 11 01:13 README.john
[email protected]:~$ ln README.john read.me
[email protected]:~$ ln -s README.john readme.1st
[email protected]:~$ ls -l README.john read.me readrme.1st
-rwxr—r— 2 john john 2471 окт. 11 01:13 read.me
lrwxrwxrwx 1 john john 11 окт. 12 01:19 readme.1st -> README.john
-rwxr—r— 2 john john 2471 окт. 11 01:13 README.john
[email protected]:~$ chrood o-r readme.1st
[email protected]:~$ ls -l README.john read.me readme.1st
-rwxrw-r— 2 john john 2471 окт. 11 01:13 read.me
lrwxrwxrwx 1 john john 11 окт. 12 01:19 readme.1st -> README.john
-rwxrw-r— 2 john john 2471 окт. 11 01:13 README.john
Для специальных файлов устройств, именованных каналов и сокетов право х не определено, а права r и w стоит воспринимать как права ввода и вывода информации на устройство и как права передачи и приема информации через средство взаимодействия.
Дополнительные атрибуты
Типичной задачей, требующей неявного делегирования полномочий, является проблема невозможности изменения пользователями свойств своих учетных записей, которые хранятся в двух файлах-таблицах — passwd и shadow, доступных на запись (и чтение) только суперпользователю root. Однако команды passwd, chsh и chfn, будучи запущены обычным пользователем, прекрасно изменяют пароль в таблице /etc/shadow и свойства пользовательской! записи в таблице /etc/passwd за счет передачи полномочий пользователя — владельца программы тому пользователю, который ее запускает.
Дополнительный атрибут SUID
-rw-r—r— 1 john john 2338 сент. 11 11:51 /etc/passwd
-rw-r—«!— 1 root shadow 1878 сент. 15 17:59 /etc/shadow
Смена пароля для john
(текущий) пароль UNIX:
Введите новый пароль UNIX:
Повторите ввод нового пароля UNIX:
passwd: пароль успешно обновлён
[email protected]:~$ ls -la /etc/passwd /etc/shadow
-rw-r—r— 1 john john 2338 сент. 11 11:51 /etc/passwd
-rw-r—— 1 root shadow 1878 окт. 19 23:51 /etc/shadow
Изменение информации о пользователе john
Введите новое значение или нажмите ENTER для выбора значения по умолчанию
—rw-r—r— 1 root root 2357 окт. 19 23:53 /etc/passwd
-rw-r—— 1 root shadow 1878 окт. 19 23:51 /etc/shadow
[email protected]:~$ ls -la /usr/bin/passwd /usr/bin/chfn
-rwsr-xr-x 1 root root 40292 сент. 13 2017 /usr/bin/chfn
-rwsr-xr-x 1 root root 41284 сент. 13 2017 /usr/bin/passwd
За счет использования атрибута SUID получается, что пользователям, запускающим программы chfn, chsh и passwd, для их исполнения временно делегируются права владельца этих программ (суперпользователя root) так, как будто сам суперпользователь их запустил.
Дополнительный атрибут SGID
[email protected]:~$ w
00:03:53 up 12 days, 13:53, 7 users, load average: 0,53, 0,51, 0,91
USER TTY FROM [email protected] IDLE XPU PCPU WHAT
mike tty2 00:03 9.00s 0.52s 0.43s -bash
john tty1 00:03 17.00s 0.51s 0.45s -bash
[email protected]:~$ ls -l /dev/tty1 /dev/tty2
crw———— 1 john tty 4, 1 окт. 20 00:03 /dev/tty1
crw———— 1 mike tty 4, 2 окт. 20 00:03 /dev/tty2
[email protected]:~$ write mike
write: mike has messages disabled
[email protected]:~$ ls -l /dev/tty2
crw—w—- 1 mike tty 4, 2 окт. 20 00:07 /dev/tty2
[email protected]:~$ write mike
write: write: you have write permission turned off.
Hi, buddy, wazzzup?
^D
[email protected]:~$
Message from [email protected] on tty1 at 00:10 …
Hey buddy, wazzup?
EOF
[email protected]:~$ ls -Ll /usr/bin/write
-rwxr-sr-x 1 root tty 9728 марта 31 2017 /usr/bin/write
Именно за счет механизма SUID/SGID различные команды позволяют обычным, непривилегированным пользователям выполнять сугубо суперпользовательские действия.
Дополнительный атрибут SGID для каталога
uid=1005(bubblegum) gid=1005(bubblegum) группы=1005(bubblegum),1007(candy)
[email protected]:/srv/klngdom$ ls -ld .
drwxr-xr-x 2 bubblegum bubblegum 4096 окт. 21 22:02 .
[email protected]:/srv/ktngdom$ touch bananaguard1
[email protected]:/srv/kingdom$ ls -l
rw-rw-r— 1 bubblegum bubblegum 0 окт. 21 22:02 bananaguard1
[email protected]:/srv/klngdom$ chgrp candy .
[email protected]:/srv/klngdom$ chmod g+ws .
[email protected]:/srv/klngdom$ ls -Id .
drwxrwsr-x 2 bubblegum candy 4096 окт. 21 22:02 .
[email protected]:/srv/kingdom$ id
uid=1001(john) gid=1001(john) группы=1001(john),1007(candy)
[email protected]:/srv/klngdom$ touch bananaguard2
[email protected]:/srv/klngdom$ ls -l
-rw-rw-r— 1 bubblegum bubblegum 0 окт. 21 22:02 bananaguard1
-rw-rw-r— 1 john candy 0 окт. 21 22:02 bananaguard2
В примере из листинга выше за счет SGID-атрибута каталога, владельцем всех файлов, помещаемых в этот каталог, автоматически назначается группа-владелец самого каталога, а создатель (владелец) файла может теперь назначать нужные права доступа для всех членов этой группы к своему файлу либо неявно при помощи реверсивной маски доступа, либо явно при помощи команды chmod.
Однако право записи в каталог дает возможность не только создавать в нем новые файлы, но и удалять любые существующие файлы (любых пользователей), что совсем, не кажется логичным. Именно атрибут t ограничивает возможность удалять чужие файлы, т. е. файлы, не принадлежащие пользователю,
пытающемуся их удалить.
Дополнительный атрибут sTicky для каталога
[email protected]: /srv/kingdom$ id
uid=1001(john) gid=1001(john) группы=1001(john),1007(candy)
[email protected]:/srv/kingdon$ ls -la
итого 8
drwxrwsr-x 2 bubblegum candy 4096 окт. 23 20:57 .
drwxr-xr-x 3 root root 4096 окт. 21 21:57 ..
-rw-rw-r— 1 bubblegum bubblegum 0 окт. 21 23:15 bananaguard1
-rw-rw-r— 1 john candy 0 окт. 21 23:24 bananaguard2
[email protected]:/srv/kingdom$ rm bananaguard1
Символьные ссылки — это файлы, которые служат указателями на другие файлы. Чтобы понять их работу, сперва вы должны понять как работают жёсткие ссылки.
Жёсткая ссылка на файл не отличима от оригинального файла, так как это ссылка на объект, на который указывает оригинальное имя файла (более точно: каждая из жёстких ссылок на файл — это ссылка на один номер inode, где номер inode — индекс в таблице inode, в которой содержатся метаданные о всех файлах файловой системы; смотрите stat(2)). Изменения файла не зависят от используемого при этом имени файла. Жёсткие ссылки не могут указывать на каталоги (чтобы не возникало петель в дереве файловой системы, что могло бы привести к неправильной работе многих программ) и на файлы из разных файловых систем (так как номера inode не уникальны в файловых системах).
Символьная ссылка — это специальный тип файла, чьё содержимое представляет собой строку, содержащую имя другого файла — файла, на который указывает ссылка (содержимое символьной ссылки можно прочитать с помощью readlink(2)). Другими словами, символьная ссылка — это указатель на другое имя, а не на сам объект. В следствии этого, символьные ссылки могут указывать на каталоги и могут указывать на файлы в разных файловых системах.
Объект с именем, на которое ссылается символьная ссылка, может не существовать. Символьную ссылку, указывающую на не существующее имя, называют оборванной ссылкой (dangling link).
Поскольку символьная ссылка и объект, на который она ссылается, сосуществуют в пространство имён файловой системы, можно запутаться при различении самой ссылки и объекта, на который она ссылается. Старые системы, команды и системные вызовы имели собственные соглашения о ссылках, специально для этого созданные. Здесь в общих чертах описаны правила, которые одинаково реализованы в Linux и других системах. Важно, чтобы локальное приложение также соответствовало этим правилам, и пользовательский интерфейс был максимально одинаков.
Владельцы, права и отметки времени символьных ссылок
Владельца и группу существующей символьной ссылки можно изменить с помощью lchown(2). Владельцы символьной ссылки учитываются только, когда символьная ссылка удаляется или переименовывается в каталоге, на котором установлен бит закрепления (sticky bit) (смотрите stat(2)).
Время последнего обращения и изменения символьной ссылки можно изменять с помощью utimensat(2) или lutimes(3).
В Linux права на символьную ссылку не учитываются при любых операциях; права всегда имеют значение 0777 (чтение, запись и исполнение для всех категорий пользователей) и его нельзя изменить.
Получение файлового дескриптора, который указывает на символьную ссылку
Для работы с самой символьной ссылкой (а не файлом, на который она указывает) нужно указать комбинацию флагов O_PATH и O_NOFOLLOW вызов open(2) вернёт файловый дескриптор, который можно передавать в аргументе dirfd в такие системные вызовы как fstatat(2), fchownat(2), fchmodat(2), linkat(2) и readlinkat(2).
По умолчанию (т. е., если не указан флаг AT_SYMLINK_FOLLOW), если name_to_handle_at(2) вызывается для символьной ссылки, то он возвращает описатель символьной ссылки (а не файла, на который она указывает). Затем с его помощью можно получить файловый дескриптор символьной ссылки (а не файла, на который она указывает), указав флаг O_PATH в последующем вызове open_by_handle_at(2). Данный файловый дескриптор можно использовать в вышеупомянутых системных вызовах для работы с самой символьной ссылкой.
Трактовка символьных ссылок в системных вызовах и командах
При работе с символьными ссылками можно воздействовать на сами символьные ссылки или на объекты, на которые они указывают. В последнем случае про приложение или системный вызов говорят, что он переходит (follow) по ссылке. Символьные ссылки могут указывать на другие символьные ссылки; в этом случае ссылки разыменовываются до нахождения объекта, который не является символьной ссылкой, символьной ссылки, которая указывает на несуществующий файл, или до обнаружения зацикливания (обнаружение зацикливания выполняется заданием максимального количества переходов по ссылкам, при превышении которого возвращается ошибка).
Есть три области, которые требуют обсуждения:
1. Использование символьных ссылок в виде имён файлов в аргументах системных вызовов. 2. Символьные ссылки, указываемые в аргументах командной строки утилит, которые не выполняют обход дерева файлов. 3. Символьные ссылки, встреченные утилитами при обходе дерева файлов (задаваемые в командной строке или встреченные как часть файла при обходе иерархии).
Системные вызовы
За исключениями, описанными ниже, все системные вызовы переходят по символьным ссылкам. Например, если есть символьная ссылка slink, которая указывает на файл с именем afile, то системный вызов open("slink" . ) вернёт файловый дескриптор, ссылающийся на файл afile.
Некоторые системные вызовы не переходят по ссылкам, а работают с самими ссылками: lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2) и unlink(2).
Другие системные вызовы могут переходить по ссылкам: faccessat(2), fchownat(2), fstatat(2), linkat(2), name_to_handle_at(2), open(2), openat(2), open_by_handle_at(2) и utimensat(2); подробности смотрите в их справочных страницах. Так как remove(3) является псевдонимом unlink(2), библиотечная функция также не переходит по символьным ссылкам. При указании символьной ссылки rmdir(2) вызов завершается с ошибкой ENOTDIR.
Вызов link(2) заслуживает отдельного описания. В POSIX.1-2001 говорится, что link(2) должен разыменовывать oldpath, если это символьная ссылка. Однако в Linux этого не делается (по умолчанию Solaris делается тоже самое, но в POSIX.1-2001 определяется как такое поведение можно получить с помощью специальных параметров компилятора). В POSIX.1-2008 изменено описание, которое позволяет реализовывать любое из этих вариантов поведения.
Команды, не выполняющие обход дерева файлов
Рассмотрим случай с символьными ссылками, указываемыми в аргументах командной строки утилит, которые не выполняют обход дерева файлов.
За исключением, описанным далее, команды переходят по ссылкам, указанным в аргументах командной строки. Например, если slink — символьная ссылка, которая указывает на файл с именем afile, то команда cat slink выведет содержимое файла afile.
Важно понимать, что это правило учитывается командами, которые не обязательно выполняют обход дерева файлов; например, команда chown file следует этому правилу, а команда chown -R file, выполняющая обход дерева, нет (последняя описана далее).
Если команде явно указано воздействовать на символьную ссылку, а не переходить по символьной ссылке, например, требуется, чтобы chown slink изменила права на файл slink, независимо от того, является ли он символьной ссылкой или нет, то нужно использовать параметр -h. В примере выше chown root slink изменяет права на файл, на который указывает slink, а chown -h root slink изменяет права на саму ссылку slink.
Есть несколько исключений из этого правила:
* Команды mv(1) и rm(1) не переходят по символьным ссылкам, указанным в аргументах, а пытаются переименовать и удалить их (заметим, если символьная ссылка указывает на файл через относительный путь, то перемещение файла в другой каталог с большой вероятностью вызовет проблемы, так как путь может оказаться неправильным). * Команда ls(1) также является исключением из этого правила. Для совместимости со старыми системами (когда ls(1) не делает обход дерева, то есть не указан параметр -R), команда ls(1) переходит по символьным ссылкам, указанным в аргументах, если задан параметр -H или -L, или если не указан параметр -F, -d или -l (команда ls(1) — единственная команда, у которой параметры -H и -L влияют на поведение даже когда не выполняется обход дерева файлов). * Команда file(1) также является исключением из этого правила. По умолчанию file(1) не переходит по символьной ссылке, указанной в аргументе. Команда file(1) переходит по символьной ссылке, указанной в аргументе, если указан параметр -L.
Команды, выполняющие обход дерева файлов
Следующие команды могут или всегда обходят дерево файлов: chgrp(1), chmod(1), chown(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1) и tar(1).
Важно понимать, что следующие правила применяются как к символьным ссылкам, обнаруженным при обходе дерева файлов, так и к символьным ссылкам, указанным в аргументах командной строки.
Первое правило применяется к символьным ссылкам, которые указывают на файлы, а не на каталоги. Операции, которые применимы к символьным ссылкам, выполняются с самими ссылками, но другие ссылки игнорируется.
Команда rm -r slink каталог удалит slink, а также все символьные ссылки, обнаруженные при обходе каталога, так как символьные ссылки могут быть удалены. Команда rm(1) никогда не удаляет файл, на который указывает slink.
При обходе дерева файлов командами соблюдаются (должны) определённые соглашения, если это возможно:
Например, команда chown -HR user slink выполнит обход файловой иерархии с корнем как у файла, указанном slink. Заметим, что здесь -H делает не тоже самое, что и флаг -h, описанный ранее. При флаге -H символьные ссылки, указанные в командной строке, будут разыменовываться и при обходе файлового дерева и как если бы пользователь указал имя файла, на которое указывает символьная ссылка.
Например, команда chown -LR user slink изменит владельца файла, на который указывает slink. Если slink указывает на каталог, то chown обойдёт дерево файлов с корнем в этом каталоге. Также, если символьные ссылки встречаются в любом файловом дереве, которое обходит chown, то с ними будет сделано тоже что и с slink.
Команды, которые по умолчанию не выполняют обход дерева файлов, игнорируют флаги -H, -L и -P, если не указан флаг -R. Также вы можете указать параметры -H, -L и -P более одного раза; последний указанный параметр определяет поведение команды. Это позволяет создавать псевдонимы команд с некоторым поведением, а затем переопределять это поведение в командной строке.
У команд ls(1) и rm(1) есть исключения из этих правил:
* Команда rm(1) работает с символьными ссылками, а не с файлами, на который они ссылаются, и поэтому никогда не переходит по символьной ссылке. Команда rm(1) не поддерживает параметры -H, -L и -P. * Для совместимости со старыми системами работа команды ls(1) чуть отличается. Если не указан параметр -F, -d или -l, то ls(1) переходит по символьной ссылке, указанной в командной строке. Если указан флаг -L, то ls(1) переходит по всем символьным ссылкам независимо от их типа и где они встретились — в командной строке или при обходе дерева.
Добавить в избранное
И зучите все, что вам нужно знать о разрешениях файлов в Linux. Также узнайте, как изменить права доступа и собственности к файлам.
По дизайну Linux – многопользовательская операционная система. В корпоративной системе было бы несколько пользователей, обращающихся к одной и той же системе. Но если любой пользователь может получить доступ и изменить все файлы, принадлежащие другим пользователям или системным файлам, это, безусловно, будет угрозой безопасности.
Вот почему UNIX и, следовательно, Linux (Linux – Unix-подобная система) имеют встроенную меру безопасности. Это гарантирует, что доступ к файлу или каталогу может быть изменен только желаемыми пользователями.
К какому файлу будет обращаться пользователь, решает два фактора в Linux:
Понимание прав собственности на файл и разрешения имеет решающее значение для пользователя Linux. Здесь мы подробно объясним эти условия.
Владение файлами в Linux
Мы можем использовать этот термин здесь, но он применим и к каталогам. Наверное, вы знаете, что каталоги – это файлы в любом случае.
Каждый файл и каталог в Linux имеет трех типов владельцев:
Пользователь
Пользователь является владельцем файла. Когда вы создаете файл, вы становитесь владельцем файла. Собственность также может быть изменена, но мы это позже.
Группа
Каждый пользователь является частью определенной группы (групп). Группа состоит из нескольких пользователей, и это один из способов управления пользователями в многопользовательской среде.
Например, если у вас есть команда разработчиков, команда QA и команды sysadmin, обращающиеся к одной и той же системе, вы должны создать для них отдельные группы. Таким образом, вы можете эффективно управлять файлами и безопасностью системы. Это экономит время, потому что вместо того, чтобы вручную добавлять разрешения для каждого пользователя, вы можете просто добавить их в группу и изменить разрешение для группы. Вы увидите, как это сделать позже в этой статье.
Даже если вы являетесь единственным пользователем системы, вы по-прежнему будете частью многих групп. Такие дистрибутивы, как Ubuntu, также создают группу с именем, аналогичным имени пользователя.
Другие
Другие – это в основном супергруппа со всеми пользователями в системе. В принципе, любой, кто имеет доступ к системе, принадлежит этой группе.
Разрешения для файлов в Linux
Каждый файл и каталог в Linux имеет три разрешения для всех трех типов владельцев:
Разрешения для файлов
- Чтение – просмотр или копирование содержимого файла
- Запись – может изменять содержимое файла
- Выполнение – может запускать файл (если его исполняемый файл)
Разрешения для каталогов
- Чтение – может перечислить все файлы и скопировать файлы из каталога
- Запись – может добавлять или удалять файлы в каталог (требуется также разрешение на выполнение)
- Выполнение – может войти в каталог
Общие сведения о разрешениях и правах доступа к файлам в Linux
Теперь, когда вы знаете основную терминологию разрешений и прав на файл, пришло время увидеть его в действии.
Если вы используете команду ls с параметром -l в файле, вы увидите такой вывод:
Позвольте нам объяснить этот результат с изображением:
Подробно весь вывод:
- File type (Тип файла) : Обозначает тип файла. d означает каталог, – означает обычный файл, l означает символическую ссылку.
- Permissions (Разрешения) : В этом поле отображается набор разрешений для файла. Я объясню это подробно в следующем разделе.
- Hard Link Count (Количество жестких ссылок) : показывает, имеет ли файл жесткие ссылки. Счет по умолчанию – один.
- User (Пользователь) : Пользователь, которому принадлежат файлы.
- Group (Группа) : Группа, у которой есть доступ к этому файлу. Одновременно может быть только одна группа.
- File Size (Размер файла) : Размер файла в байтах.
- Modification timestamp (Время модификации) : Дата и время последнего изменения файла.
- Filename (Имя файла) : Очевидно, имя файла или каталога.
Теперь, когда вы поняли вывод команды ls -l, давайте сосредоточимся на части разрешения файла.
В приведенной выше команде вы видите разрешение файла, подобное этому в девятизначном формате :
Каждая буква обозначает конкретное разрешение:
- r: разрешение на чтение
- w: разрешение на запись
- x: выполнить разрешение
- -: не установлено разрешение
Разрешения всегда находятся в порядке читать, писать и выполнять, т. е. rwx. И тогда эти разрешения устанавливаются для всех трех своего рода владельцев (см. раздел прав собственности) в порядке: Пользователь, Группа и Другое.
Эта картина лучше объяснит:
Итак, если вы посмотрите на приведенную выше картинку, вы можете сказать следующие вещи о разрешениях файлов:
Теперь, если вы снова увидите всю команду ls -l, вы можете прочитать права на файлы и права собственности вместе.
Файл andreyex.txt принадлежит пользователю andreyex а также andreyex имеет разрешение на чтение, запись и выполнение. Все члены группы andreygroup имеют доступ на чтение и запись к этому файлу, в то время как все остальные имеют доступ только к чтению этого файла.
Корневой пользователь имеет полномочия суперпользователя и, как правило, он имеет права на чтение, запись и выполнение всех файлов, даже если вы не видите их в файл разрешения.
Один пользователь может быть членом нескольких групп, но только основная группа пользователя является владельцем группы файла, созданного пользователем. Основная группа пользователя может быть найдена с помощью идентификатора команды –gn . Оставьте имя пользователя пустым, если вы пытаетесь найти свою собственную основную группу.
Теперь, когда вы знаете, как узнать разрешения на файл, давайте посмотрим, как вы можете изменить разрешение и права собственности на файл.
Изменить права доступа к файлам в Linux
Вы можете использовать команду CHMOD для изменения разрешений на файл в Linux.
Общая информация : Разрешения назывались режимом доступа и, следовательно, CHMOD была короткая форма изменения режима доступа.
Существует два способа использования команды chmod:
- Абсолютный режим
- Символический режим
Использование chmod в абсолютном режиме
В абсолютном режиме разрешения представлены в числовой форме (точнее, восьмеричная система). В этой системе каждое разрешение файла представлено числом.
- r (чтение) = 4
- w (написать) = 2
- x (выполнить) = 1
- – (без разрешения) = 0
С помощью этих числовых значений вы можете комбинировать их, и, таким образом, один номер может использоваться для представления всего набора разрешений.
| Число | разрешение |
| 0 | – |
| 1 | -x |
| 2 | -w- |
| 3 (т.е. 2 + 1) | -wx |
| 4 | r- |
| 5 (т.е. 4 + 1) | г-х |
| 6 (т.е. 4 + 2) | rw- |
| 7 (т.е. 4 + 2 + 1) | rwx |
Можете ли вы догадаться о разрешении файла в цифрах в файле andreyex.txt в нашем примере? Это пишут, это 754.
Теперь, когда вы знаете, какой номер представляет это разрешение, давайте посмотрим, как изменить разрешение файла с помощью этих знаний.
Предположим, вы хотите изменить разрешение файла на andreyex.txt, чтобы каждый мог читать и писать, но никто не может его выполнить? В этом случае вы можете использовать команду chmod следующим образом:
Если вы перечислите andreyex.txt сейчас, вы увидите, что разрешение было изменено.
Использование chmod в символическом режиме
Проблема с абсолютный режим заключается в том, что вы должны всегда предоставлять три номера для всех трех владельцев, даже если вы хотите изменить разрешение для одного владельца.
Здесь вы можете использовать символический режим с помощью команды chmod.
В символическом режиме владельцы обозначаются следующими символами:
- u = пользовательский пользователь
- g = владелец группы
- o = другое
- a = все (пользователь + группа + прочее)
Символический режим использует математические операторы для выполнения изменений разрешения:
- + для добавления разрешений
- – для удаления разрешений
- = для переопределения существующих разрешений с новым значением
Теперь, когда вы знаете, давайте посмотрим, как использовать команду chmod в символическом режиме.
В нашем предыдущем примере, если вы хотите добавить разрешение на выполнение для владельца группы, вы можете использовать команду chmod следующим образом:
Если вы сейчас просмотрите разрешения для этого файла, вы увидите, что теперь добавлено разрешение на выполнение:
Вы также можете объединить несколько изменений разрешений в одну команду. Предположим, вы хотите удалить права на чтение и запись и добавить разрешения на выполнение для других. Вы также хотите добавить разрешение на выполнение для пользователя, Вы можете сделать все это по одной команде:
Полученные разрешения будут такими:
Если вы хотите одновременно изменить разрешения для всех трех пользователей, вы можете использовать его следующим образом:
Это приведет к удалению разрешения на выполнение для всех.
Теперь, когда вы знаете, как изменить разрешение файла, давайте посмотрим, как изменить права собственности на файл.
Изменение владельца файла в Linux
Чтобы изменить право собственности на файл, вы можете использовать команду chown. Вы можете легко догадаться, что chown означает владельца изменения.
Вы можете изменить владельца пользователя файла следующим образом:
Если вы хотите изменить пользователя и группу, вы можете использовать команду cown следующим образом:
Если вы просто хотите изменить группу, вы можете использовать команду chwon таким образом:
или команду chgrp, специально используемую для изменения владельца группы файла или каталога. Вы можете догадаться, что команда chgrp означает группу изменений.
В нашем примере до сих пор, если вы хотите изменить владельца и группу пользователей на root, вы можете использовать команду chown следующим образом:
Это изменит право собственности на файл на root как для пользователя, так и для группы.
Бонус Совет: Есть ли приоритет в разрешениях на файлы?
Подумайте о ситуации, когда обычный пользователь не имеет никаких разрешений, группа имеет разрешение на чтение, в то время как другие имеют права на чтение и запись.
Теперь, если пользователь andreyex пытается прочитать файл с помощью команды cat или less, сможет ли он это сделать? Ответ – нет, потому что у него нет разрешения на чтение.
Но пользователь andreyex является частью группы andreygroup, и у группы есть доступ на чтение. Другой имеет право на чтение и запись. Это должно означать, что каждый (включая пользователя andreyex) может читать и писать файл, не так ли? Неправильно!
В Linux приоритет от пользователя, а затем от группы, а затем и от другого. Система Linux проверяет, кто инициировал этот процесс (в нашем примере cat или less). Если пользователь, инициировавший этот процесс, также является владельцем пользователя, устанавливаются биты прав пользователя.
Если владелец файла не инициировал этот процесс, система Linux проверяет группу. Если пользователь, инициировавший процесс, находится в той же группе, что и группа владельца файла, установлен бит групповых разрешений.
Если этот владелец процесса даже не входит в группу в качестве владельца группы файла, тогда устанавливаются другие биты разрешения.
Что еще?
Существуют некоторые расширенные разрешения для файлов, такие как установка Sticky bit для предотвращения удаления файлов и т. д.
Надеюсь, вам понравилась статья, и теперь у вас есть лучшее понимание того, как права доступа к файлам работают в Linux.
Если у вас есть какие-либо вопросы или предложения или вы просто хотите сказать спасибо, пожалуйста, оставьте комментарий ниже. Если вам понравилась статья, пожалуйста, поделитесь ею в социальных сетях или на разных форумах. Это поможет нам и другим пользователям Linux.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Ниже мы разберем понятие жестких и символических ссылок в Windows, расскажем про их основное предназначение и ключевые отличия. Также Вы сможете научиться быстро создавать ссылки стандартными способами Windows или при помощи специального ПО.
Содержание:
Символические ссылки
Такой функционал имеет некоторые схожести с ярлыками, но в отличие от них, создается жесткая привязка символической ссылки к конкретному месту. Использование таких ссылок позволяет экономить место винчестере, а также получать своеобразную точку доступа к информации между различными файловыми системами, не заполняя носитель лишними копиями данных.
Жесткие ссылки
Жесткая ссылка или Hard Link имеет схожий функционал с символическими ссылками, но её ключевыми отличиями являются:
- Возможность работы только в одной конкретной файловой системе.
- Возможность работы в пределах только одного логического раздела.
- Жесткая ссылка так же, как и символическая ссылка воспринимается системой как оригинальный файл, но жесткая ссылка сохраняет свою оригинальность (все файлы жестких ссылок действительно являются оригиналами), в то время как при изменении настоящего файла или каталога символической ссылки, такие ссылки потеряют свою актуальность, поскольку им некуда будет ссылаться.
Таким образом жесткие ссылки имеют гораздо меньший круг применения, но обеспечивают безопасность при использовании, поскольку все жесткие ссылки не зависят от своего оригинала.
Как можно применить символические ссылки?
Символические ссылки могут иметь большое применение. Для примера, такие ссылки можно использовать при работе с виртуальными машинами или для более удобной работы с облачными хранилищами. Символьные ссылка позволяют не тратить ресурс жесткого диска, перемещая большие папки и файлы, а просто создавать символические ссылки, которые будут иметь такие же характеристики, полную работоспособность и другие возможности данных, куда была создана символьная ссылка.
Таким образом можно перемещать и синхронизировать объемные папки под видом символических ссылок в хранилища или перемещать программы с основного компьютера на виртуальную машину, без установки, траты места и с сохранением работоспособности утилиты. Это позволяет редактировать, работать или изменять структуру данных с виртуальной машины, синхронизировано с данными на реальном носителе ПК, при этом не открывая доступ с виртуальной машины на реальный компьютер.
Для примера, попробуем создать символическую ссылку на программу для восстановления данных RS Partition Recovery, чтобы сэкономить место, перенести её на другой диск и в то же время не переустанавливать утилиту в корень папки на новом системном диске.
Важно! Функции символьных ссылок доступны с Windows Vista. Более старые версии ОС не поддерживают работу с ними, поскольку в их функционале присутствует возможность создания только жестких и мягких (ярлыков) ссылок.
Процесс создания символической ссылки выглядит следующим образом:
Разберем подробнее каждый из пунктов команды.
В нашем случае успешное создание символьной ссылки выглядит следующим образом:
Пробуем запустить утилиту через символическую ссылку.
Программа RS Partition Recovery (как и любые другие программы, архивы, игры и т.д) успешно заработала через символическую ссылку.
В данном случае каждая часть команды отвечает за следующее:
Как упростить создание символических и жестких ссылок?
Для неподготовленных пользователей работа в командной строке может оказаться достаточно трудной и неудобной, поэтому многие предпочитают использовать специальный утилиты, добавляющие возможность быстрого создания ссылок различных типов из контекстного меню (меню, которое появляется при нажатии по файлу правой кнопкой мыши).
Одной из самых популярных программ для быстрого создания ссылок из контекстного меню является Link Shell Extension.
Процесс создания символической ссылки с дополнительными утилитами выглядит следующим образом:
Независимо от метода создания, ссылки будут функционировать в штатном режиме.
Часто задаваемые вопросы
Это сильно зависит от емкости вашего жесткого диска и производительности вашего компьютера. В основном, большинство операций восстановления жесткого диска можно выполнить примерно за 3-12 часов для жесткого диска объемом 1 ТБ в обычных условиях.
Если файл не открывается, это означает, что файл был поврежден или испорчен до восстановления.
Пожалуйста, используйте бесплатные версии программ, с которыми вы можете проанализировать носитель и просмотреть файлы, доступные для восстановления.
Сохранить их можно после регистрации программы – повторное сканирование для этого не потребуется.
О Den Broosen
Автор и инженер компании RecoverySoftware. В статьях делится опытом восстановлению данных на ПК и безопасному хранению информации на жестких дисках и на RAID массивах .
Читайте также: