Если Вы загрузили тот пакет, выполнение rpm -ivh package_name.rpm
. Или нажмите System/Administration/AddRemove Software, используйте инструмент GUI для поиска 'хромового' пакета.
Это проблема многопользовательских систем, особенно если у вас их несколько. ;) Нет на самом деле хорошего способа делать то, что вы хотите. На ум приходит
Наиболее эффективным подходом будет возврат к общепринятой практике. На большинстве (по крайней мере) систем Linux существуют некоторые группы, которые имеют обычно общие GID. В качестве примера можно привести пользователей
, которые имеют GID 100
на большинстве дистрибутивов Linux. Если бы вы могли иметь соответствующую учетную запись пользователя в этой группе, вы могли бы
Первый и второй пункт легко выполнимы (chown
, chmod
)). Третья точка получения немного сложнее.
Часть "группа-владелец" относительно проста: Вы можете установить бит SGID во всех каталогах на диске. Бит SGID, применяемый к каталогам, говорит ядру вести себя как BSDish: BSD делает каждый файл/каталог, созданный в определённой группе каталогов, принадлежащим не основной группе процесса создания файла/каталога (как в Linux), а владельцу родительского каталога.
Бит разрешения немного жёстковат. На разрешения вновь создаваемых файлов/каталогов (среди прочего) влияет маска umask
- битовая маска, подсказывающая, какие биты не устанавливать, если они не указаны явно. Например, общим значением umask
является 022
, что означает, что биты записи для "группы" и "других" обычно не должны устанавливаться. Вы можете изменить ваше umask
на 002
, сказав, что вы не хотите, чтобы разрешения на запись были очищены для группы, но недостаток в том, что вы не можете установить это значение на основе каталога, и вы обычно не хотите, чтобы разрешения на запись для вашего основного набора групп для каждого создаваемого файла.
Это можно решить с помощью ACL: В ACL вы можете установить маску mask
и набор разрешений default
, который применяется ко всем файлам и каталогам, созданным внутри каталога с этим набором ACL. Таким образом, одним из возможных решений вашей проблемы будет
См. setfacl(1)
, и acl(5)
для получения более подробной информации.
Владелец и группа файла хранятся в виде чисел. Таким образом, файл будет принадлежать uid=1005, независимо от того, к какому пользователю (или вообще ни к какому) в системе он подключен.
Изменение пользователя/группы на "никого" не исправит вашу проблему. Тогда только никому из пользователей (или членов ничейной группы) не будет разрешен доступ к файлам.
К сожалению, я не думаю, что есть способ отключить проверку прав на ext4. Смотрите, например, Можно ли отключить разрешения на файлы файловой системы ext3 или ext4?
Там есть Другой подобный вопрос и BindFS предлагается там:
mkdir /home/$user/sda1
bindfs -u $user -g $group /mnt/sda1 /home/$user/sda1
Пользователи OSX предлагают ZOONERS
Опция Mount, описанная так:
Игнорировать Поле собственности на весь объем. Это приводит к тому, что все объекты отображаются как принадлежащие пользователю ID 99 и группа ID 99. Идентификатор пользователя 99 интерпретируется как текущий Эффективный идентификатор пользователя, а в группе ID 99 используется напрямую и переводится на `" неизвестно ".
Andreas Wiese говорит, что если у вас есть общий идентификатор группы на всех хостах, вы можете решить проблему с помощью setgid
бита и ACL
Я задаю вопрос Предопределенные идентификаторы групп в разных дистрибутивах Linux?
После собственных исследований выяснилось, что такие группы существуют во всех затронутых дистрибутивах: sys
group share id 3
на Debian, Ubuntu, RedHat, Fedora, CentOS, Suse, FreeBSD, OpenBSD, NetBSD, MacOSX, Solaris.
С этим:
$ sudo chgrp -R sys /mnt/data/dir
$ sudo chmod -R g+s /mnt/data/dir
$ sudo setfacl -R -m g:sys:rwx /mnt/data/dir
$ sudo setfacl -R -d -m g:sys:rwx /mnt/data/dir
и вкусом этого:
$ sudo adduser user sys
вы пользователь
сможете читать/писать любой файл на /dir
.
Большинство задач могут выполнять setgid
бит, но, к сожалению, у вас обычно мало контроля над umask
. Поэтому ACL используется для обеспечения полного решения.
См. также: