Desventajas de umask 077?

¿Cuáles son las desventajas de tener una máscara de seguridad restrictiva de 077? Muchas distribuciones (creo que todas, ¿excepto Red Hat?) Tienen una umask predeterminada de 022, configurada en / etc / profile. Esto parece demasiado inseguro para un sistema que no es de escritorio, al que acceden varios usuarios, y la seguridad es motivo de preocupación.

En una nota relacionada, en Ubuntu, los directorios de inicio de los usuarios también se crean con 755 permisos, y el instalador afirma que esto es para facilitar a los usuarios compartir archivos. Asumiendo que los usuarios se sienten cómodos configurando permisos a mano para compartir archivos, esto no es un problema.

¿Qué otras desventajas hay?

022 hace las cosas convenientes. 077 hace las cosas menos convenientes, pero dependiendo de las circunstancias y el perfil de uso, puede no ser menos conveniente que tener que usar sudo.

Yo diría que, como sudo, el beneficio de seguridad real y medible que obtienes de esto es insignificante en comparación con el nivel de dolor que te infliges a ti y a tus usuarios. Como consultor, me han despreciado por mis puntos de vista y me han sudodesafiado a romper numerosas sudoconfiguraciones, y todavía tengo que tomar más de 15 segundos para hacerlo. Tu llamada.

Conocerlo umaskes bueno, pero es solo una hojuela de maíz en el "desayuno completo". Tal vez deberías preguntarte a ti mismo "Antes de ir a la basura con las configuraciones predeterminadas, cuya consistencia deberá mantenerse en todas las instalaciones y deberá documentarse y justificarse para las personas que no son tontas, ¿qué va a comprar esto? ¿yo?"

Umask también es un bash integrado que los usuarios individuales pueden configurar en sus archivos de inicialización de shell ( ~/.bash*), por lo que no es capaz de aplicarlo fácilmente umask. Es solo un defecto. En otras palabras, no te está comprando mucho.

La desventaja más obvia es cuando comienzas a crear archivos / directorios en un directorio compartido, esperando que otros usuarios accedan a ellos.

Por supuesto, solo es cuestión de no olvidar establecer la máscara de usuario correcta antes de hacer cosas que todos los usuarios deben compartir.

Otra advertencia (no es realmente una desventaja, una vez que lo sabe) es cuando comienza a hacer cosas de sudo, como instalar programas locales, gemas de rubí, huevos de pitón (obviamente, no los paquetes de administración del sistema operativo), crear archivos de configuración, etc.

Tendrás problemas porque la sesión de sudo hereda el umask, por lo que solo el root podrá acceder a los archivos / directorios que crees. sudo se puede configurar para configurar automáticamente la máscara de usuario de la manera que desee: esta pregunta se trata en superuser.com .

Umask no sería apropiado si intenta controlar lo que otros usuarios pueden ver entre sí. Sin embargo, si tiene y trabaja con numerosos archivos que son sensibles hasta el punto de que pedir permiso para acceder a ellos es menos molesto / arriesgado que simplemente dejar que las personas vean lo que quieran, una buena máscara de 077 sería una buena idea.

Tengo algunos archivos confidenciales en un servidor de archivos que administro. Creo que establecer una máscara de usuario restrictiva y luego tener un script periódico, tal vez un trabajo cron para establecer permisos más específicos para elementos en ciertas carpetas sería una solución ideal para mí. Cuando configure esto, volveré a publicar aquí y le haré saber cómo funcionó.

@ [Los chicos golpean sudo] Comienza un nuevo hilo para ello, podría tomar varios hilos propios y este hilo es sobre umask.

Las aplicaciones de terceros que usan sus propios sistemas de instalación pueden tener suposiciones integradas sobre la umask predeterminada del sistema.

Como ejemplo práctico, después de actualizar una base de datos Oracle 10 en un sistema que tenía la umask establecida en 077, las aplicaciones en el mismo sistema no pudieron acceder a la base de datos ... porque las bibliotecas son esenciales para los clientes de la base de datos y los directorios de las bibliotecas. estaban ubicados en, ahora estaban protegidos para que solo el oracleusuario pudiera acceder a ellos, lo que obviamente no era cómo se suponía que funcionaban las cosas.

Resulta que el proceso del actualizador de Oracle no se ocupó específicamente de que los permisos de las bibliotecas del cliente permitieran que otros usuarios los usaran, sino que se basó en la suposición de que los archivos agregados por el actualizador se crearían con umask 022 y así serían utilizables por defecto. Después de algunos chmod -R a+rXcomandos juiciosos para los directorios apropiados, todo volvió a estar bien.

De acuerdo, esto podría haberse evitado tratando la oraclecuenta como una cuenta especial del sistema con umask 022 estándar, y restringiendo el umask 077 solo a cuentas de usuario con capacidad de inicio de sesión ... pero creo que este es un buen ejemplo de cómo el "endurecimiento general" "las decisiones pueden tener efectos secundarios imprevistos.

.rpmy los .debpaquetes llevan información de permiso explícito para cualquier archivo que contengan, por lo que generalmente no tienen el riesgo de errores de este tipo.

Tengo esta linea en mi ~/.zshrc

umask 0077

configurarlo globalmente probablemente no sea una buena idea, pero configurarlo como el predeterminado en su archivo rc probablemente no va a dañar o incluso configurarlo como el predeterminado en el /etc/skel/.rcarchivo. Sin embargo, todo el sistema causará problemas.

Causará problemas en un servidor; por ejemplo, cuando se ejecutan varias aplicaciones como diferentes usuarios que intentan acceder a archivos de diferentes usuarios. Como apache leyendo archivos de configuración o pi-hole leyendo dnsmasq.conf. Simplemente ejecútelo en usuarios que podrían beneficiarse de él como directorios de inicio individuales, no establecidos explícitamente /etc/profile.