J'ai ajouté un utilisateur à un groupe, mais les autorisations de groupe sur les fichiers n'ont toujours aucun effet

J'ai changé les autorisations d'un fichier ( chmod g+w testfile) et l'exécution ls -l testfiledonne:

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

J'ai ensuite ajouté un utilisateur à ce groupe (" / etc / group " a une user1:x:1000:user2ligne), mais je n'arrive pas à modifier ce fichier en tant qu'utilisateur2. Pourquoi cela est-il ainsi?

user2 doit se déconnecter et se reconnecter. Les autorisations de groupe fonctionnent de cette façon:

• Lorsque vous vous connectez, vos processus doivent avoir l'appartenance à un groupe dans votre groupe principal mentionné dans /etc/passwd, plus tous les groupes dans lesquels votre utilisateur est mentionné /etc/group. (Plus précisément, le pw_gidchamp dans getpw(your_uid), plus tous les groupes dont votre utilisateur est un membre explicite . Au /etc/passwd- delà et /etc/group, les informations peuvent provenir d'autres types de bases de données utilisateur telles que NIS ou LDAP.) Le groupe principal devient l' ID de groupe efficace du processus et les autres groupes deviennent ses ID de groupe supplémentaires .
• Lorsqu'un processus effectue une opération qui nécessite l'appartenance à un certain groupe, comme l' accès à un fichier , ce groupe doit être l'ID de groupe effectif ou l'un des ID de groupe supplémentaires du processus.

Comme vous pouvez le voir, votre modification de l'appartenance au groupe de l'utilisateur ne prend effet que lorsque l'utilisateur se connecte. Pour l'exécution des processus, il est trop tard. L'utilisateur doit donc se déconnecter et se reconnecter. Si cela vous pose trop de problèmes, l'utilisateur peut se connecter à une session distincte (par exemple sur une autre console ou avec ssh localhost).

Sous le capot, un processus ne peut que perdre des privilèges (ID utilisateur, ID de groupe, capacités). Le noyau démarre le initprocessus (le premier processus après le démarrage) en cours d'exécution en tant que root, et chaque processus est finalement issu de ce processus¹. Le loginprocessus (ou sshd, ou la partie de votre gestionnaire de bureau qui vous connecte) est toujours en cours d'exécution en tant que root. Une partie de son travail consiste à supprimer les privilèges root et à basculer vers l'utilisateur et les groupes appropriés.

Il y a une seule exception: exécuter un programme setuid ou setgid . Ce programme reçoit des autorisations supplémentaires: il peut choisir d'agir sous différents sous-ensembles des appartenances du processus parent ainsi que l'appartenance supplémentaire à l'utilisateur ou au groupe propriétaire de l'exécutable setxid. En particulier, un programme racine setuid a des droits root, il peut donc tout faire²; c'est ainsi que les programmes aiment suet sudopeuvent faire leur travail.

¹ _{Il existe parfois des processus qui ne sont pas dérivés d'init (initrd, udev) mais le principe est le même: démarrer en tant que root et perdre des privilèges au fil du temps.}
² _{Sauf les cadres de sécurité à plusieurs niveaux tels que SELinux.}

Vous devrez peut-être demander à l'utilisateur2 de se déconnecter et de se reconnecter (ou simplement d'essayer de se connecter pour créer une nouvelle session de connexion). Vérifiez la sortie de id --groupspour afficher les identifiants de groupe numériques d'un utilisateur.

sudo su $(whoami)

Essentiellement la même solution de contournement que ssh localhost , mais utilisable sans avoir un serveur ssh installé.

Tant que vous avez racine. Mais si vous venez d'ajouter un nouveau groupe et de modifier les autorisations, vous le faites probablement.

Il y a un cas où la déconnexion de l'utilisateur n'aide pas - si vous utilisez la directive ssh ControlMaster pour l'hôte. Si vous ajoutez votre compte à un groupe, fermez la session et reconnectez-vous dans la même connexion ControlMaster, la session ne vous montrera toujours aucun nouvel abonnement. Vous devrez forcer la connexion principale avec

ssh -O exit hostname

avant de vous reconnecter.