Razones detrás de los grupos y usuarios predeterminados en Linux


14

Al echar un vistazo a la administración predeterminada de usuarios y grupos en algunas distribuciones habituales de Linux (respectivamente ArchLinux y Debian), me pregunto dos cosas al respecto y las consecuencias de modificar la configuración y configuración predeterminadas.

El valor predeterminado de USERGROUPS_ENABin /etc/login.defsparece ser "yes", que se refleja en "Por defecto, también se creará un grupo para el nuevo usuario" que se puede encontrar en el useraddhombre, por lo que cada vez que se crea un nuevo usuario, un el grupo se crea con el mismo nombre y solo este nuevo usuario. ¿Tiene algún uso o es solo un marcador de posición?

Siento que estamos perdiendo una parte de la gestión de derechos como usuario / grupo / otros al hacer esto. ¿Sería malo tener un grupo de "usuarios" o "clientes habituales" o como quieran llamarlo, que es el grupo predeterminado para cada usuario en lugar de tener el suyo?

Segunda parte de mi pregunta, que todavía se basa en lo que he visto en Arch y Debian: hay muchos usuarios creados por defecto (FTP, HTTP, etc.). ¿Les sirve de algo o solo existen por razones históricas?

Estoy pensando en eliminarlos, pero no quiero romper nada que pueda usarlo, pero nunca he visto nada que lo haga, y no tengo idea de qué podría. Lo mismo ocurre con los grupos predeterminados (tty, mem, etc.) a los que nunca he visto pertenecer ningún usuario.


Si me das algo de tiempo, te daré una buena respuesta. Solo soy un tipo lento. Puede ser de 30 minutos o más.
eyoung100

El punto principal de todos estos grupos es para los programas set-group-id.
Barmar

2
La primera pregunta está muy cerca de esta .
Leiaz

@ECarterYoung: Por supuesto, puedes tomarte tu tiempo, ¡gracias por esto!
Horgix

@Leiaz: Me di cuenta de eso, pero aún quería preguntar "¿Sería malo tener un grupo de" usuarios "o" clientes habituales "o como quieran llamarlo, que es el grupo predeterminado para cada usuario en lugar de tener el suyo?" parte, y mantuvo lo que era antes como una introducción. Principalmente publiqué en StackOverflow pero fui dirigido aquí.
Horgix

Respuestas:


13

Grupos por usuario

Yo tampoco veo mucha utilidad en los grupos por usuario. El caso de uso principal es que si un usuario desea permitir el acceso de "amigos" a sus archivos, puede agregar al usuario amigo a su grupo. Pocos sistemas que he encontrado en realidad lo usan de esta manera.

Cuando USERGROUPS_ENABen /etc/login.defsse establece en "no", useraddagrega todos los usuarios creados al grupo definido /etc/default/useraddpor el GROUPcampo. En la mayoría de las distribuciones, esto se establece en el GID 100que generalmente corresponde al usersgrupo. Esto le permite tener una gestión más genérica de los usuarios. Luego, si necesita un control más preciso, puede agregar manualmente estos grupos y agregar usuarios a ellos que tenga sentido.

Grupos creados por defecto

La mayoría de ellos surgieron por razones históricas, pero muchos todavía tienen usos válidos hoy en día:

  • disco es el grupo que posee la mayoría de los dispositivos de disco
  • lp posee un puerto paralelo (y algunas veces está configurado para derechos de administrador en cups)
  • uucp a menudo posee puertos serie (incluidos los puertos serie USB)
  • Se requiere CDROM para montar privilegios en una unidad de CD
  • Algunos sistemas usan la rueda para los derechos de sudo; algunos no
  • etc.

Los scripts de fondo utilizan otros grupos. Por ejemplo, mangenera archivos temporales y similares cuando se ejecuta; su proceso usa el grupo man para algunos de esos archivos y generalmente se limpia después de sí mismo.


Sin embargo, según la especificación básica básica de Linux , solo 3 usuarios que son root, bin y daemon son absolutamente obligatorios . La razón detrás de los otros grupos es:

El propósito de especificar usuarios y grupos opcionales es reducir la posibilidad de conflictos de nombres entre aplicaciones y distribuciones.

Por lo tanto, parece que es mejor mantener a estos grupos en su lugar. Es teóricamente posible eliminarlos sin romperse, aunque para algunos, las cosas "misteriosas" pueden comenzar a no funcionar correctamente (por ejemplo, algunas páginas de manual no se procesan si se mata a ese grupo, etc.). No hace ningún daño dejarlos allí, y generalmente se supone que todos los sistemas Linux los tendrán.


¿Dónde puedo encontrar más información sobre el hombre que genera archivos temporales? Con una página man abierta, ps aux | grep manno me muestra ningún proceso que se ejecute bajo el grupo man, y a find -group man /tampoco me muestra nada. Intenté con man 2.6.7.1 en una instalación estándar de Archlinux.
Horgix

4

Pregunta 1: Razonamiento para el mismo usuario y grupo

Hola, soy ecyoung y eres horgix. Vamos a trabajar todos los días e iniciamos sesión en el mismo servidor Linux que los programadores. Un día, no hace mucho tiempo, nuestro administrador del sistema decidió facilitar la creación y el mantenimiento de los usuarios, por lo que desactivó la USERGROUPS_ENABopción y puso a todos los usuarios existentes en el nuevo usersgrupo.


Esto facilitó la creación de usuarios, pero no el mantenimiento, ya que todos los usuarios pueden acceder a todos los archivos de otros usuarios. En un entorno corporativo, este es un gran no no debido a cosas como Sarbanes Oxley y Segregación de deberes . Si creo el archivo A, el bit de grupo se establece en el grupo de usuarios, lo que significa que todos los usuarios pueden al menos leer el archivo A. Si el administrador del sistema es perezoso, en algunos casos todos los usuarios pueden RW file A. Esto derrota a Sarbanes Oxley y SoD porque los departamentos separados no deberían poder leer mucho menos escribir el documento de cualquier otra persona.


Con Usuario / Grupo habilitado si creo un documento como ecyoung, solo tengo derechos rwx sobre él. Como nadie más está en mi grupo, cuando abren mi documento, ven una página en blanco con una advertencia. Esto hace cumplir Sarbanes-Oxley y SoD. Si invito a otros usuarios, a esos usuarios se les permite el acceso rw, y al hacerlo sé que lo que ven no volverá a morderme ni a ellos. Como otros han dicho, si está en casa, esa separación puede no ser importante para usted. Si determina eso, puede desactivar la opción de forma segura y todos los usuarios se agregarán a unusers grupo con un GID de 100. Consulte la pregunta 2 a continuación.

Hipotético :
trabajas en TI y Louis trabaja en nómina. Louis mantiene la hoja de impuestos y nómina en su directorio de inicio, pero ambos están en el grupo de usuarios, por lo que abre su directorio de inicio porque está marcado + r para los usuarios y encuentra su hoja de cálculo. Encontrará el monto de su salario en la lista, junto con los de Joe y Fred. ¿Crees que a Joe y Fred les gustaría que supieras su salario?


Pregunta 2: ID de grupo del 0 al 500

Las ID de grupo y, por el contrario, las ID de usuario 0 - 500 están reservadas para cuentas del sistema y acceso a dispositivos. Consulte la tabla de grupos de sistemas preconfigurados para ver la lista de cuentas estándar. No elimine estas cuentas a mano. Por ejemplo, si desea eliminar el usuario ftp, elimine el demonio ftp con su sistema de administración de paquetes. Hacerlo también eliminará la cuenta del sistema. Los servicios del sistema incluyen, pero no se limitan a:

  • El servicio de impresión CUPS
  • El demonio del servidor MySQL
  • El demonio del servidor FTP
  • El servidor web Apace
  • El X Server Socket para conexiones remotas
  • El demonio del sistema de sonido ALSA
  • El servicio DBUS

Hay otros, así que si otros lectores desean agregar o eliminar de la lista de Servicios anterior, hágalo.


55
Bonito hipotético, pero un fracaso. 1. Los permisos predeterminados generalmente están enmascarados 022, lo que significa que otros tienen acceso de lectura de todos modos. 2. El sysad no solo es vago, sino incompetente, ya que debería haber creado grupos de acuerdo con el departamento y haber asignado el grupo correcto durante la creación de la cuenta, en lugar de asignar todo a algún grupo. El USERGROUPS_ENABdebe permanecer apagado entonces. Deshabilitar USERGROUPS_ENAB! = Poner a todos los usuarios en el mismo grupo.
muru

@ECarterYound para la primera parte: veo lo que quieres decir con la protección de acceso, y corrígeme si me equivoco, pero tener a todos los usuarios en un usersgrupo no debería ser un problema con la gestión de derechos adecuada en los grupos, eso no es dar exactamente lo mismo derechos para el grupo que el propietario. Entonces, ¿el único punto bueno de haber USERGROUPS_ENABactivado es tener un mantenimiento más fácil, ya que le permite mantener los derechos predeterminados al crear archivos y directorios sin dejar de tener acceso restringido para otros usuarios?
Horgix

Eso sería correcto, pero muchas personas no administran los Grupos correctamente si son usuarios domésticos. No puedo verificar esto con seguridad, pero creo que los encargados del mantenimiento crearon la opción para apuntalar la administración de permisos.
eyoung100

3

Si todos compartimos un grupo predeterminado, como en los viejos tiempos, entonces necesitamos establecer nuestra umask en 077 para bloquear el grupo. Si el valor predeterminado es yo, entonces puedo configurar la umask en 027, ahora si configuro un directorio de archivos en un grupo compartido, este grupo puede leer. No tengo que meterme con los modos también.

Este es solo un ejemplo, pero en general es una forma de deshabilitar grupos, hasta que los necesite, de manera que sea más fácil activarlos y administrarlos.


1

Los grupos por usuario le permiten tener "privacidad en su directorio personal" y "colaboración fácil en carpetas compartidas". Sin grupos por usuario, puede tener cualquiera pero no ambos. Los detalles siguen:

Unix es un sistema multiusuario, ya sea un servidor de archivos de la empresa o una PC con 2 usuarios. La "privacidad en su directorio personal" puede realizarse de varias maneras:

Establezca "umask 077" para que los archivos se creen con rw para usted y sin permisos para otros. Alternativamente, 027 o 022 para que algunos o todos puedan leer pero no escribir sus archivos. La desventaja obvia es que no puedes colaborar en una carpeta compartida porque los demás no pueden trabajar en archivos que creas allí debido a permisos estrictos. Puede cambiar los permisos de dichos archivos, pero eso es "demasiado trabajo" y, a menudo, se olvida.

Para colaborar, desea algo como "umask 7" para que tanto usted como el grupo propietario puedan leer y escribir los archivos que cree. Esto es ideal para carpetas compartidas y grupos que consisten en todas las personas que necesitan acceso compartido. ¡Pero pierdes la privacidad en tu carpeta de inicio!

¡El grupo por usuario es la solución! Utiliza umask 7, por lo que todos los archivos que crea obtienen "rw para usted y rw para el grupo". Los archivos en su directorio de inicio se crean con su grupo personal como "grupo propietario", por lo que nadie más puede acceder a esos archivos a pesar del permiso "group rw". Porque nadie más que tú está en ese grupo en particular.

Todavía puedes colaborar en carpetas compartidas. Los archivos en la carpeta compartida obtienen "rw" para el grupo propietario, y el administrador del sistema configuró la carpeta compartida para que un grupo compartido (llamado colaboradores) sea el propietario del grupo para los archivos allí. Esto se hace creando este grupo de colaboradores, con todos los usuarios colaboradores como miembros. Luego, el administrador establece la propiedad del grupo de la carpeta compartida en "colaboradores" y establece el permiso SETGID para la carpeta compartida. Con SETGID activado, todo lo creado en la carpeta compartida obtendrá el mismo propietario del grupo que la carpeta compartida, es decir, el grupo de "colaboradores". Y con umask 7 (o alternativamente 2), todas las personas en este grupo tendrán acceso de lectura + escritura y podrán colaborar.


0

Originalmente, los procesos de Unix podían pertenecer a un grupo a la vez (solía haber un chgrp(1)comando que solicitaba la contraseña del grupo almacenada en el campo de contraseña de vestigio en /etc/groups). Los sistemas Plus fueron utilizados por un grupo de usuarios muy unido. Tenía sentido tener a todos en el usersgrupo y compartir cosas en todo el sistema mediante permisos grupales. Sin conciencia de seguridad real, poca sospecha de la docena de usuarios más o menos. Todo era local, en la misma máquina. No hay red para compartir cosas, por ejemplo, a través de un blog más o menos.

Los sistemas Unix actuales tienen cientos de usuarios, los requisitos de seguridad son más estrictos y los usuarios (y procesos) pueden pertenecer a varios grupos. Ofrezca a cada uno de los usuarios (más desorientados) un grupo en el hogar y permita alejarse de él para compartir. O use ACL.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.