Pourquoi les fichiers de mon répertoire personnel sont-ils créés en écriture mondiale malgré un umask plus restrictif?


10

J'ai réalisé que les autorisations pour les nouveaux fichiers et répertoires se comportent un peu étrangement. Tout d'abord, umask semble renvoyer la bonne réponse:

$ umask
0002

Cela signifie un accès complet pour mon utilisateur et mon groupe, aucun accès en écriture pour le reste du monde, aucun suid. Mais si je crée un fichier dans mon $ HOME, voici à quoi il ressemble:

$ ls -l testfile 
-rw-rw-rw- 1 robe robe 0 mar 16 12:58 testfile

c'est-à-dire, donner un accès en écriture à tout le monde. La même chose se produit avec les répertoires:

$ ls -ld testdir
drwxrwxrwx 2 robe robe 6 mar 16 13:00 testdir

Je pense que c'est la même chose que d'avoir umask 0000, pas 0002. J'ai recherché dans tous / etc une instance d'umask qui change le 0002 ou 0022 par défaut, mais n'en a trouvé aucun. Il s'agit d'une installation par défaut de CentOS 5.5. Une idée de pourquoi cela se produit-il?


3
Sur quel type de système de fichiers se trouve votre répertoire personnel?
mattdm

4
Et comment créez-vous testfileet testdir?
mattdm

3
@mattdm, vous aviez raison d'insister: c'est XFS. J'ai oublié que nous avons des volumes séparés pour / home, / var et plusieurs autres. Bien que j'utilise souvent XFS et n'avais pas vu ce comportement. Comment peut-il être lié?
rsuarez

2
acl peut remplacer umask localement. Est-il possible que vos répertoires soient montés avec acl?
Faheem Mitha

3
Hmm, apparemment, xfs a toujours activé acl. il peut donc ne pas apparaître dans votre / etc / fstab. Essayez d'exécuter getfacl sur vos partitions / répertoires.
Faheem Mitha

Réponses:


3

Je ne sais pas s'il est approprié de répondre à ma propre question. Les éditeurs, s'il vous plaît, donnez votre avis à ce sujet si ce n'est pas le cas. Merci d'avance.

Je pense que j'ai résolu ce mystère: le problème était l'absence d'une ACL par défaut sur les volumes XFS. Voici l'entrée ACL pour / srv / backups, l'un des répertoires concernés:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

Chaque fois que je faisais un "test mkdir" ou un "fichier de test tactile", il y avait des autorisations 777. J'ai donc fait ceci:

setfacl -m d:u::rwx /srv/backups

Laisser l'ACL comme ceci:

# file: srv/backups
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

Auparavant, il n'y avait (soi-disant) pas d'ACL, mais maintenant il y en a. Je peux voir le signe "+" attaché aux autorisations lorsque je fais un "ls -l". Et comme par magie, maintenant "mkdir test" et "touch testfile" fonctionnent avec les autorisations attendues:

# ls -l testfile 
-rw-r--r-- 1 root root 0 Dec 20 10:00 testfile
# ls -ld testdir
drwxr-xr-x+ 2 root root 6 Dec 20 10:00 testdir

Je ne sais pas pourquoi cela se produit. Je suppose que XFS n'aime pas ne pas avoir d'ACL par défaut et se comporte étrangement quand cela se produit. De plus, j'ai vu cela se produire uniquement dans CentOS, pas dans Debian / Ubuntu. Peut-être que c'est lié à la version XFS dans le noyau, ou quelque chose comme ça. Aucune idée.

Quoi qu'il en soit, cela règle l'affaire pour moi. Merci beaucoup pour toutes les suggestions :-)


Répondre à votre propre question est parfaitement acceptable .
Keith Thompson

0

L'appel creat peut spécifier explicitement des permissions qui ont priorité sur umask.

Vous n'avez pas répondu à la façon dont vous créez testfile,testdir.

Créez le fichier à l'aide de touch testfile, puis répertoriez et publiez les autorisations


Désolé pour le retard. J'ai testé en utilisant "touch testfile", et aussi "mkdir testdir", avec des résultats similaires. umask semble être réglé sur "0000", car ils sont créés avec les autorisations 777.
rsuarez

0

Essayez un getfacl .dans le répertoire dans lequel vous créez votre fichier de test, pour voir s'il existe un acl par défaut affectant les autorisations.


1
Non, pas d'ACL par défaut. Il semble être lié à XFS d'une manière ou d'une autre, car cela ne se produit que dans les volumes XFS. Mais merci quand même.
rsuarez

-1

Recherchez simplement la variable USERGROUPS_ENAB sur /etc/login.defs

Leur commentaire afin de le désactiver # USERGROUPS_ENAB oui

Si vous souhaitez également modifier le umask de votre utilisateur actuel, vous devez d'abord suivre la procédure précédente et effectuer les opérations suivantes.

exemple pour 027

echo "umask 027" >> ~ / .bashrc && pkill -KILL -u votre_nom_utilisateur_ici

echo "umask 027" >> ~ / .bashrc cette commande définira une valeur par défaut umask pour votre profil

cela vous obligera à vous déconnecter

après vous être reconnecté

exécutez à nouveau la commande umask et voyez si cela fonctionne pour vous

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.