Implicaciones de agregar manualmente un usuario al grupo de personal

Esto surgió como un problema de permisos en Ubuntu 16.04. No pude eliminar algunas bibliotecas R instaladas en /usr/local/lib/R/site-library . Resultó que no tenía permiso. El directorio era propiedad de root y el grupo era staff .

Resolví temporalmente el problema de permisos agregando manualmente mi usuario al grupo de staff .

 sudo usermod -a -G staff myusername # *see blockquote before using this!* 

Eso me permite eliminar las bibliotecas de IDE.

Sin embargo, cuando intenté buscar más información en el grupo de personal y no pude encontrar ningún material definido sobre el tema. Ni siquiera para lo que el grupo estaba destinado principalmente. Solo pude suponer que se utiliza para dar un acceso ‘mejorado’ similar a los usuarios en ciertos directorios.

¿Hay alguna implicación de agregar manualmente un usuario al grupo de personal?

Además, ¿hay algún comando para conocer los permisos de todo el sistema para un grupo? Por ejemplo, ¿cuáles son todos los directorios para los cuales el personal del grupo tendrá permiso de escritura?

Gracias.

Edición: debo agregar aquí que usar adduser lugar de usermod es una opción mucho más sensata para esta operación [consulte el comentario a continuación]

sudo adduser myusername staff

De acuerdo, como me dijo un @muru , estoy publicando una respuesta a mi propia pregunta, en la medida de lo posible. El archivo de file:///usr/share/doc/base-passwd/users-and-groups.html incluye información detallada sobre grupos y permisos. Un espejo de esta página se puede encontrar aquí: Usuarios y Grupos

En consecuencia:

personal

Permite a los usuarios agregar modificaciones locales al sistema ( /usr/local , /home ) sin necesidad de privilegios de root. Compare con el grupo adm , que está más relacionado con el monitoreo / seguridad.

Tenga en cuenta que la capacidad de modificar /usr/local es efectivamente equivalente al acceso a la raíz (ya que /usr/local está intencionalmente en las rutas de búsqueda antes de /usr ), por lo que solo debe agregar usuarios de confianza a este grupo. Tenga cuidado en los entornos que utilizan NFS, ya que la adquisición de privilegios de otro usuario no root es a menudo más fácil en tales entornos.

Por supuesto que adm ya está en mis groups así que puedo hacer dmesg . Pero tuve que agregarme manualmente al staff

El registro de una lista de directorios propiedad del personal muestra que todos estos pertenecen a uno de estos:

 sudo find / -maxdepth 8 -type d -group staff -perm -g=w >>stafflog.txt /var/local /usr/local/lib /usr/local/share 

No es de extrañar que la membresía del personal me dé acceso de escritura a mis bibliotecas de lenguaje de progtwigción compartidas.

verificando permiso para uno de estos:

 ls -al /var/local drwxrwsr-x 2 root staff 4096 Apr 11 2014 . drwxr-xr-x 16 root root 4096 Aug 3 15:55 .. 

De modo que, aparentemente, el sistema realiza el truco de personal configurando el bit de los directorios ( setguid ). Para que cualquier usuario o proceso cree los archivos en ese directorio, el archivo siempre se ejecuta con los permisos compartidos en todo el grupo de personal. Mira aquí

Sin embargo, todavía me pregunto si puedo mantenerme segura en este grupo. En mi opinión, debería ser bastante seguro dado que se trata de una computadora portátil a la que, en el peor de los casos, se accederá a través de una LAN confiable, a través de smb o ssh. Las palabras ‘efectivamente equivalente al acceso de root’ me asustan. Cualquier pensamiento sobre esto es bienvenido.