web-dev-qa-db-fra.com

Implications de l'ajout manuel d'un utilisateur au groupe de personnel

Ceci est apparu comme un problème de permission sur Ubuntu 16.04. Je n'ai pas pu supprimer certaines bibliothèques R installées dans /usr/local/lib/R/site-library. Il s'est avéré que je n'avais pas la permission. Le répertoire appartenait à root et le groupe était staff.

J'ai temporairement résolu le problème des autorisations en ajoutant manuellement mon utilisateur au groupe staff.

Sudo usermod -a -G staff myusername    

# *see blockquote before using this!*

Cela me permet de supprimer les bibliothèques de l'IDE.

Cependant, lorsque j'ai essayé de rechercher plus d'informations sur le groupe du personnel et que je n'ai pas pu trouver de matériel précis sur le sujet. Pas même ce à quoi le groupe était principalement destiné. Je devine seulement qu'il est utilisé pour donner un accès "amélioré" similaire aux utilisateurs de certains annuaires.

L'ajout manuel d'un utilisateur au groupe d'employés a-t-il des implications?

En passant, y a-t-il une commande permettant de connaître les autorisations système pour un groupe? Par exemple, quels sont tous les répertoires pour lesquels le personnel du groupe aura le droit d'écriture?

Merci.

Edit: Je dois ajouter ici que l’utilisation de adduser au lieu de usermod est une option beaucoup plus judicieuse pour cette opération [voir le commentaire ci-dessous]

Sudo adduser myusername staff

16.04permissionsusersgroups
6
R.S.

Ok, comme poussé par @ mur , je poste une réponse à ma propre question, dans la mesure du possible. Le fichier file:///usr/share/doc/base-passwd/users-and-groups.html contient des informations détaillées sur les groupes et les autorisations. Un miroir de cette page peut être trouvé ici: tilisateurs et groupes

En conséquence:

personnel

Permet aux utilisateurs d'ajouter des modifications locales au système (/usr/local, /home) sans avoir besoin des privilèges root. Comparez avec le groupe adm, qui est davantage lié à la surveillance/sécurité.

Notez que la possibilité de modifier /usr/local équivaut en réalité à un accès racine (puisque /usr/local figure intentionnellement sur des chemins de recherche précédant /usr), vous ne devez donc ajouter que des utilisateurs de confiance à ce groupe. Soyez prudent dans les environnements utilisant NFS, car l'acquisition des privilèges d'un autre utilisateur non root est souvent plus facile dans de tels environnements.

Bien sûr, adm est déjà dans mon groups pour que je puisse faire dmesg. Mais je devais ajouter manuellement moi-même à staff

L'enregistrement d'une liste de répertoires appartenant au personnel indique que tous appartiennent à l'un des répertoires suivants:

Sudo find / -maxdepth 8 -type d -group staff -perm -g=w >>stafflog.txt

/var/local
/usr/local/lib
/usr/local/share

Pas étonnant que les membres du personnel me donnent un accès en écriture à mes bibliothèques de langages de programmation partagées.

vérification de l'autorisation pour l'un de ceux-ci:

ls -al /var/local

drwxrwsr-x  2 root staff 4096 Apr 11  2014 .
drwxr-xr-x 16 root root  4096 Aug  3 15:55 ..

Donc, apparemment, l’astuce du personnel est exécutée par le système en définissant le bit des répertoires (setguid). Afin que, quel que soit l'utilisateur ou le processus créant les fichiers dans ce répertoire, le fichier s'exécute toujours avec les autorisations partagées sur le groupe de personnel. voir ici

Cependant, je me demande encore si je peux rester en toute sécurité dans ce groupe. À mon avis, cela devrait être assez sûr étant donné qu’il s’agit d’un ordinateur portable auquel on aura accès dans le pire des cas via un réseau local sécurisé, via smb ou ssh. Les mots "équivalent à l'accès root" me font peur. Toute pensée à ce sujet est la bienvenue.

6
R.S.