Comments 32
Владелец пользователя, владелец группы — мягко говоря странная терминология, через которую через силу продираешься...
У меня нулевой опыт как переводчика, но нужно как-то так:
изменение владельца > смена владельца;
изменить владельца > поменять владельца;
изменение владельца группы > смена группы-владельца (группы владельцев);
Владелец пользователя, владелец группы — мягко говоря странная терминология
Наверное, в оригинале было owner (или owner user) и owner group? тогда ясно, что это слабое знание языка. Должно быть «пользователь-владелец» (или просто «владелец») и "(основная) группа, в которую входит пользователь-владелец" (или просто «группа пользователя-владельца», либо вообще «группа владельца»).
На это же намекает и фраза из статьи, переведённая лучше основной части текста (впрочем, и тут хвостик подкачал, так что я его отрежу):
Пользователь, который создает файл, автоматически становится владельцем этого файла, а основная группа этого пользователя автоматически становится ...
Мягко говоря...
А я ещё своей статьи стеснялся.
Разрешение на выполнение — это то, что вам нужно для выполнения файла.
Ну это не совсем так. Точнее, это вообще не так. Допустим так:
$ chmod a-x /usr/bin/cal
$ /usr/bin/cal
bash: /usr/bin/cal: Permission denied
$ /lib64/ld-linux-x86-64.so.2 /usr/bin/cal
Октября 2019
Вс Пн Вт Ср Чт Пт Сб
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31
Не говоря уже о том, что для запуска скрипта достаточно указать интерпретатор.
Ну или банально
$ cat /usr/bin/cal > /tmp/cal
$ chmod +x /tmp/cal
$ /tmp/cal
Октября 2019
Вс Пн Вт Ср Чт Пт Сб
....
… что делает Linux практически полностью невосприимчивым к вирусам.
Ооочень спорно. Очень.
Только кто-то с административными правами на каталог может применять разрешение на выполнение.
Простите, это вообще о чём? Что такое "административные права"? Выставить разрешение на выполнение, ровно как и любой другой аттрибут прав, может тот, кто имеет доступы W и X на каталог с файлом. Ну либо владелец соответствующх CAP, не помню точное название, условно, root.
Интересный факт: насколько я помню, если весь раздел подмонтирован с опцией noexec (как раньше было в Android для SD-карты — может, и сейчас), то для запуска ELF-файла не поможет даже явное указание линкера — он просто будет пытаться отобразить куски файла в память с PROT_EXEC, но получит ошибку. Тут уже нужно патчить линкер или что-то в этом роде (и сразу идёт лесом возможность иметь одну копию для всех сегментов кода — ну или нужно костылить ещё больше).
Вы правы, вот такое будет
/mnt/1/cal: error while loading shared libraries: /mnt/1/cal: failed to map segment from shared object
Но noexec не так часто выставлен и обычно у процесса есть место, куда можно записать, а значит просто копируем туда нужный бинарь и поехали.
Я бы скорее поставил на механизмы SELinux и тп, но их часто отключают, ибо слооожна =(
Видимо, это защита просто, чтобы неповадно было подгружать с SD-карты so-шку (десять раз переписанную злоумышленником), а потом обрабатывать пароли. Что-то вроде "разрешим грузить shared objects только оттуда, где действуют права доступа, а не с FAT". Я писал не с точки зрения взломщика, а с точки "хитрого на выдумки" бывшего пользователя телефона с 512Mb флеша и 32Gb SD-картой (так и не допилил тогда эту задумку).
Пример некорректный. А что не так? Вот я пользователь max, захотел себе пользователя max, сделал adduser max и стал владельцем пользователя max ))) Аналогично и с группой.
Для меня это очевидные вещи, но может только для меня.
В таком случае как бы вы перевели? On Linux, every file and every directory has two owners: a user and a group owner.
И: On creation, the user who creates the file becomes the user owner, and the primary group of that user becomes the group owner. Может так? Пользователь, который создаёт файл становится владельцем этого файла, а первичная группа, в которую входит этот же пользователь, так же становится владельцем этого файла.
— Есть скрипт run.sh, принадлежит root:root, права 744.
— Есть пользователь moe. Понятно что он не может запустить run.sh, т.к. не прав.
— Делаю chmod u+s run.sh от рута. В итоге получаем
-rwsr--r--. 1 root root 34 Oct 2 11:29 run.sh— Пользователь все равно не может запустить
[root@localhost bin]# ls -l
total 4
-rwsr--r--. 1 root root 34 Oct 2 11:29 run.sh
[root@localhost bin]# su moe
[moe@localhost bin]$ ./run.sh
bash: ./run.sh: Permission denied
[moe@localhost bin]$
Таким образом можно дать пользователю право выполнить конкретное приложение от рута без выдачи соответствующих прав на все остальные команды и занесения в sudoers. Например, если повесить этот бит на /usr/bin/apt, то пользователь сможет попытаться выполнять обновления софта (но поскольку на debconf и dpkg мы этот бит не повесили — при установке он получит ошибку).
Но если добавить o+x на файл, и модифицировать его, например один рутовый скрипт вызывает другой рутовый скрипт.
[root@localhost bin]# ls -l
total 8
-rwxr--r--. 1 root root 33 Oct 2 11:51 app.sh
-rwsr--r-x. 1 root root 48 Oct 2 11:53 run.sh
[root@localhost bin]# cat run.sh
#!/bin/bash
echo "Trying to start..."
./app.sh
[root@localhost bin]# ./run.sh
Trying to start...
Hello, world
[root@localhost bin]# su moe
[moe@localhost bin]$ ./run.sh
Trying to start...
./run.sh: line 4: ./app.sh: Permission denied
Все равно не хочет.
правильным будет
Должно быть: «Однако, если вы создаете общий каталог группы (скажем, /groups/account) и убедитесь, что разрешение SGID применено к этому каталогу и что группа account установлена как владелец группы для этого каталога, все файлы, созданные в этом каталоге и во всех его подкаталогах, также получают группу account как владельца группы по умолчанию.»
Разрешение на выполнение — это то, что вам нужно для выполнения файла. Оно никогда не будет установлено по умолчанию
Поэтому используйте setfacl -m d:g:sales:rx /data, если вы хотите, чтобы групповые продажи прочитали и выполнили все, что когда-либо будет создано в каталоге /data.
Как-то противоречиво. Я как-то особо никогда этим вопросом не задавался, но вот сел посмотреть — беглая проверка в ближайшем ssh-теминале показывает что executable все равно не появится хоть ты задавись этим setfacl'ом. Ни сейчас, ни потом, ни после ребута.
Что не так?
upd: по каким-то причинам ключик d не работает, ни как d:u:username:rwx, ни как -d -m u:username:rwx
Словом, пока из двух утверждений выше, более верно первое.
1. Откройте терминал, в котором вы являетесь пользователем linda. Создать пользователя можно командой useradd linda, добавить пароль passwd linda.
2. Создайте в корне каталог /data и подкаталог /data/sales командой mkdir -p /data/sales. Выполните cd /data/sales, чтобы перейти в каталог sales. Выполните touch linda1 и touch linda2, чтобы создать два пустых файла, владельцем которых является linda.
Пользователь linda ведь не сможет создать каталог в корне?
Автор спасибо!
А можно удалить или переписать эту статью? Простите за резкость, но начинающим она только навредит, а опытным не нужна. Основной вред в том, что из-за недочётов в переводе именно для систематизации знаний она совершенно негодится, только для бездумного копирования конкретных примеров "чтобы ... сделайте ...". И то - не без риска получить результат не соответствующий ожидаемому.
Я прошёл бы мимо, но статья в перых результатах гугла по запросу, например, "sticky bit", а это накладывает на автора некоторую ответственность.
Права в Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)