Inconvénients d'Umask 077?

Quels sont les inconvénients, pour avoir un umask restrictif de 077? Beaucoup de distributions (je crois que toutes, sauf Red Hat?) Ont un umask par défaut de 022, configuré dans / etc / profile. Cela semble beaucoup trop peu sûr pour un système non-desktop, auquel plusieurs utilisateurs accèdent, et la sécurité est préoccupante.

Sur une note connexe, sur Ubuntu, les répertoires personnels des utilisateurs sont également créés avec des autorisations 755, et le programme d'installation indique que cela permet aux utilisateurs de partager plus facilement des fichiers. En supposant que les utilisateurs sont à l'aise de définir manuellement les autorisations pour rendre les fichiers partagés, ce n'est pas un problème.

Quels sont les autres inconvénients?

022 rend les choses pratiques. 077 rend les choses moins pratiques, mais selon les circonstances et le profil d'utilisation, cela pourrait ne pas être moins pratique que d'avoir à utiliser sudo.

Je dirais que, comme sudo, l'avantage de sécurité réel et mesurable que vous en retirez est négligeable par rapport au niveau de douleur que vous infligez à vous-même et à vos utilisateurs. En tant que consultant, j'ai été méprisé pour mes opinions sudoet mis au défi de casser de nombreuses sudoconfigurations, et je n'ai pas encore pris plus de 15 secondes pour le faire. Ton appel.

Connaître, umaskc'est bien, mais ce n'est qu'un seul Corn Flake dans le "petit déjeuner complet". Vous devriez peut-être vous demander "Avant de partir avec des configurations par défaut, dont la cohérence devra être maintenue entre les installations, et qui devra être documentée et justifiée pour les personnes qui ne sont pas timides, qu'est-ce que ça va acheter moi?"

Umask est également un bash intégré qui peut être réglé par des utilisateurs individuels dans leurs fichiers d'initialisation du shell ( ~/.bash*), vous n'êtes donc pas vraiment en mesure d'appliquer facilement le umask. C'est juste un défaut. En d'autres termes, cela ne vous achète pas beaucoup.

L'inconvénient le plus évident est lorsque vous commencez à créer des fichiers / répertoires dans un répertoire partagé, en attendant que d'autres utilisateurs y accèdent.

Bien sûr, il ne s'agit que de ne pas oublier de définir le bon umask avant de faire des choses qui doivent être partagées par tous les utilisateurs.

Une autre mise en garde (pas vraiment un inconvénient, une fois que vous en êtes conscient) est lorsque vous commencez à faire des trucs sudo tels que l'installation de programmes locaux, des pierres précieuses rubis, des œufs python (pas des packages de gestion du système d'exploitation évidemment), la création de fichiers de configuration, etc.

Vous aurez des ennuis car umask est hérité par la session sudo, donc seul root pourra accéder aux fichiers / répertoires que vous créez. sudo peut être configuré pour définir automatiquement le umask comme vous le souhaitez: cette question est traitée sur superuser.com .

Umask ne serait pas approprié si vous essayez de contrôler ce que les autres utilisateurs peuvent voir les uns des autres. Cependant, si vous possédez et travaillez avec de nombreux fichiers qui sont sensibles au point que demander la permission d'y accéder est moins gênant / risqué que de simplement laisser les gens voir ce qu'ils veulent, un umask de 077 serait une bonne idée.

J'ai des fichiers sensibles sur un serveur de fichiers que je gère. Je pense que définir un umask restrictif puis avoir un script périodique, peut-être qu'un travail cron pour définir des autorisations plus spécifiques sur les éléments de certains dossiers serait une solution idéale pour moi. Quand j'aurai mis cela en place, je posterai ici et je vous ferai savoir comment cela a fonctionné.

@ [Les gars dénigrant sudo] Commencez un nouveau thread pour cela, cela pourrait prendre plusieurs threads et ce thread est sur umask.

Les applications tierces qui utilisent leurs propres systèmes d'installation peuvent avoir des hypothèses intégrées sur le umask par défaut du système.

À titre d'exemple pratique, après la mise à jour d'une base de données Oracle 10 sur un système sur lequel umask a été défini sur 077, les applications sur le même système n'ont pas pu accéder à la base de données ... car les bibliothèques essentielles aux clients de la base de données et les répertoires les bibliothèques étaient situés dans, étaient désormais protégés afin que seul l' oracleutilisateur puisse y accéder, ce qui n'était évidemment pas la façon dont les choses étaient censées fonctionner.

Il s'avère que le processus de mise à jour Oracle n'a pas spécifiquement pris soin que les autorisations des bibliothèques clientes permettent aux autres utilisateurs de les utiliser, mais s'est plutôt appuyé sur l'hypothèse que les fichiers ajoutés par le programme de mise à jour seraient créés avec umask 022 et donc utilisables. par défaut. Après quelques chmod -R a+rXcommandes judicieuses pour les répertoires appropriés, tout allait bien à nouveau.

Certes, cela aurait pu être évité en traitant le oraclecompte comme un compte système spécial avec umask 022 standard, et en limitant l'umask 077 à des comptes d'utilisateurs réellement connectés uniquement ... mais je pense que c'est un bon exemple de la façon dont le durcissement de la couverture "Les décisions peuvent avoir des effets secondaires imprévus.

.rpmet les .debpackages contiennent des informations d'autorisation explicites pour tous les fichiers qu'ils contiennent, de sorte qu'ils n'ont généralement pas le risque d'erreurs de ce type.

J'ai cette ligne dans mon ~/.zshrc

umask 0077

le définir globalement n'est probablement pas une bonne idée, mais le définir comme valeur par défaut dans votre fichier rc ne va probablement pas nuire ni même le définir comme valeur par défaut dans le /etc/skel/.rcfichier. à l'échelle du système entraînera des problèmes.

Cela causera des problèmes sur un serveur; par exemple, lorsque plusieurs applications s'exécutent en tant qu'utilisateurs différents essayant d'accéder aux fichiers de différents utilisateurs. Comme apache lisant des fichiers de configuration ou pi-hole lisant dnsmasq.conf. Il suffit de l'exécuter sur les utilisateurs qui pourraient en bénéficier, comme les répertoires personnels individuels, non explicitement définis dans/etc/profile .