Я добавил пользователя в группу, но групповые разрешения на файлы по-прежнему не влияют

Я изменил разрешения файла ( chmod g+w testfile) и работает ls -l testfileдает:

-rwxrwxr-x 1 user1 user1 0 2011-01-24 20:36 testfile

Затем я добавил пользователя в эту группу (в строке « / etc / group » есть user1:x:1000:user2строка), но мне не удается отредактировать этот файл как user2. Почему это так?

user2 Необходимо выйти и снова войти. Разрешения группы работают следующим образом:

• Когда вы входите в систему, ваши процессы получают членство в группе, указанной в вашей основной группе /etc/passwd, плюс все группы, в которых упоминается ваш пользователь /etc/group. (Более точно, pw_gidполе getpw(your_uid), плюс все группы которых ваш пользователь является явным членом . За /etc/passwdи /etc/group, информация может поступать из других видов пользовательских баз данных , таких как NIS или LDAP.) Основная группа становится процессом в эффективный идентификатор группы и другие группы становятся его дополнительными идентификаторами групп .
• Когда процесс выполняет операцию, которая требует членства в определенной группе, например, для доступа к файлу , эта группа должна быть либо действующим идентификатором группы, либо одним из идентификаторов дополнительных групп процесса.

Как вы можете видеть, ваше изменение членства в группе пользователя вступает в силу только тогда, когда пользователь входит в систему. Для запущенных процессов это слишком поздно. Таким образом, пользователь должен выйти из системы и снова войти в нее. Если это слишком сложно, пользователь может войти в отдельный сеанс (например, на другой консоли или с помощью ssh localhost).

В рамках процесса процесс может только потерять привилегии (идентификаторы пользователей, идентификаторы групп, возможности). Ядро запускает initпроцесс (первый процесс после загрузки), выполняющийся от имени пользователя root, и каждый процесс в конечном итоге происходит от этого процесса¹. loginПроцесс (или sshd, или часть вашего рабочего стола менеджера , который регистрирует вас) все еще работает как корень. Частью его работы является удаление привилегий root и переключение на соответствующих пользователей и группы.

Есть одно исключение: выполнение программы setuid или setgid . Эта программа получает дополнительные разрешения: она может действовать в различных подмножествах членства родительского процесса плюс дополнительное членство в пользователе или группе, которой принадлежит исполняемый файл setxid. В частности, корневая программа setuid имеет root-права, поэтому может делать все²; Вот как программы любят suи sudoмогут делать свою работу.

Occasion _{Иногда возникают процессы, которые не являются производными от init (initrd, udev), но принцип тот же: запускайте с правами root и со временем теряйте привилегии.}
² _{Запрет многоуровневых сред безопасности, таких как SELinux.}

Вам может потребоваться, чтобы user2 вышел из системы и снова вошел в нее (или просто попытайтесь выполнить ssh'ing, чтобы создать новый сеанс входа в систему). Проверьте выходные данные, id --groupsчтобы показать числовые идентификаторы группы для пользователя.

sudo su $(whoami)

По сути тот же обходной путь, что и ssh localhost, но может быть использован без установленного ssh-сервера.

Пока у вас есть root. Но если вы только что добавили новую группу и изменили разрешения, вы, скорее всего, это сделаете.

Существует случай, когда выход пользователя из системы не помогает - если вы используете директиву ControlMaster ssh для хоста. Если вы добавите свою учетную запись в группу, выйдете из системы и снова войдете в систему в том же соединении с ControlMaster, сеанс по-прежнему будет показывать, что у вас нет нового членства. Вам придется принудительно разорвать соединение Master с

ssh -O exit hostname

прежде чем войти снова.