Comment configurer `umask` pour toute la session gnome?

Utiliser Gnome 3.18. Je partage des fichiers entre d'autres membres de la famille, mais le umask par défaut sur ma distribution (archlinux) est 0022. Ainsi, chaque fichier / répertoire créé n'est pas accessible en écriture pour notre groupe commun.

J'ai essayé de mettre umask 0002en /etc/profilemais la session gnome utilise encore 0022. Cela fonctionne pour un shell bash de connexion, cependant.

J'ai également essayé d'ajouter cette ligne /etc/pam.d/system-auth: session required pam_umask.so umask=0002 elle a le même effet que celle de /etc/profile. j'ai essayé

Si je change manuellement le umask dans un shell gnome-terminal, je lance une application à partir de celui-ci, disons gedit, alors les fichiers créés par celui-ci ont les autorisations voulues. Si je lance gedit à partir des menus gnome, ce n'est pas le cas. Donc, mon problème est vraiment de définir le umask pour la session gnome, et je ne peux pas trouver où le faire.

EDIT (pour répondre au commentaire de Gilles): J'utilise gdm 3.18 comme DM. J'ai également essayé d'ajouter la ligne pam_umask dans /etc/pam.d/gdm-launch-environment. Tous les autres gdm-*fichiers contiennent comprend de sessiondu system-authfichier, donc ils ne devraient pas avoir besoin de plus. Cela ne change rien.

/etc/login.defscontient UMASK 077mais USERGROUPS_ENAB yesqui doit également définir le umasksur 0077ou 0007pour les utilisateurs dont le groupe principal est le nom d'utilisateur.

Le seul fichier qui contient 022pour umask /etcest /etc/profilemais c'était mon premier essai.

Quant à /etc/Xsession.d, je n'ai pas ce répertoire. De plus, comme wayland est maintenant le serveur d'affichage par défaut, je ne suis pas sûr que le umask devrait être défini dans le cadre de l'initialisation X, même si je l'utilise toujours moi-même.

Certaines applications Gnome sont lancées par systemd --user, auquel cas umask est défini par systemd sur 0022quelle que soit la valeur configurée pour pam_umask . Je ne suis au courant d'aucune solution de contournement, mais j'ai ouvert un problème sur tracker problème systemd github. Ce problème est également signalé sur Gnome bugzilla .

Umask set using pam_umaskfonctionne comme prévu pour les applications qui ne sont pas lancées par systemd --user.

Une solution de contournement est suggérée sur Ubuntu bugzilla  pour placer des remplacements de service systemd sur toutes les applications affectées.

Pour enquêter sur vous-même

Vous pouvez répertorier les processus en cours d'exécution sur votre système sous forme d'arborescence (processus parent / enfant) en utilisant:

pstree -Tapu

Trouvez les PID pour: (1) l'instance de votre session de systemd --user ; (2) une application lancée par lui , comme gedit, qui apparaîtra comme processus enfant à systemd --user ; et (3) un processus dans votre session non lancé par systemd --user .

Comparez les umasks rapportés dans procfs :

grep Umask /proc/<pid>/status

systemd --user lui-même (1) et les processus non lancés par lui (3) devraient avoir le bon umask qui a été défini par pam_umask . Les processus lancés par systemd --user (2) auront umask of 0022.

Le problème est celui mentionné par Sebasth. J'ai essayé beaucoup de choses, mais j'ai trouvé une solution de contournement qui consiste à écraser l'UMask (par utilisateur) de dbus:

$ systemctl --user edit dbus

Dans le fichier qui s'ouvre, écrivez simplement:

[Service]
UMask=002 # This is the umask I want to use

Le fichier est enregistré dans .config / systemd / user / dbus.service.d / override.conf et remplace le umask par défaut de dbus, qui je présume est hérité de systemd --user, puisque dbus est lancé par lui. Déconnectez-vous et reconnectez-vous et les applications gnome doivent utiliser le umask spécifié. Juste une solution de contournement, mais cela fonctionne pour moi.

Au lieu de cela, umaskvous pouvez utiliser l' usergroupsoption pour pam_umask, avec cet utilisateur et ce groupe a les mêmes autorisations, que la façon Unix classique de partager des dossiers.

# /etc/pam.d/login or
# /etc/pam.d/common-session or system-auth
session optional pam_umask.so usergroups

Pour définir umask par défaut à l'échelle du système, vous devrez l'activer en premier lieu, ce qui est assez bien expliqué ici:

http://manpages.debian.org/cgi-bin/man.cgi?query=pam_umask&sektion=8

Le lien ci-dessus est pour debian et ubuntu mais le même pour tous les autres systèmes linux.

Pour l'activer umask (qui est peut-être déjà en place), vous devez ajouter une ligne à /etc/pam.d/common-session:

session optional pam_umask.so

Une fois activé, vous pouvez ensuite le configurer dans:

/etc/login.defs

Je vois que vous avez déjà trouvé ce fichier, il vous suffit donc de définir:

# The permission mask is initialized to this value. If not specified,
# the permission mask will be initialized to 022.
UMASK           077

Et définissez-le UMASK sur 0002 ou tout ce que vous souhaitez.

Cela définira la valeur par défaut à l'échelle du système, ce qui signifie que tous les utilisateurs devront récupérer le umask à partir de là, sauf s'ils ne le spécifient pas autrement dans leur .profile ou .bashrc

Pour la session de connexion: ajoutez umask 0002à votre $HOME/.profile(ou /etc/profile).

Pour la session Gnome: ajoutez umask 0002à votre$HOME/.gnomerc

EDIT: Pour que systemd définisse l'umask de la session gnome, j'ai créé un fichier umask.conf sous /etc/systemd/system/display-manager.service.d/ avec les lignes suivantes:

[Service]
UMask=0002

Après le redémarrage de la machine, cela permet désormais à tous les processus user.slicede se conformer au umask que vous souhaitez. La déconnexion n'était pas suffisante pour que les modifications aient lieu, je vous conseille donc de redémarrer votre machine avant d'effectuer les tests sur les masques de processus.

 Informations supplémentaires:

• OS: CentOS7.4
• DE: Gnome3

Je voulais juste ajouter que les pam_umaskpages de manuel fournissent de très bonnes informations pour vous aider à comprendre d'où vient votre umask. Plus précisément:

pam_umask est un module PAM pour définir le masque de création de mode fichier de l'environnement actuel. L'umask affecte les autorisations par défaut attribuées aux fichiers nouvellement créés.

Le module PAM essaie d'obtenir la valeur umask à partir des emplacements suivants dans l'ordre suivant:

·   umask= argument
·   umask= entry of the users GECOS field
·   pri= entry of the users GECOS field
·   ulimit= entry of the users GECOS field
·   UMASK= entry from /etc/default/login
·   UMASK entry from /etc/login.defs

Comme quelqu'un l'a dit, vous devez le configurer dans le common-sessionfichier du répertoire /etc/pam.d.

Notez que les connexions qui n'utilisent pas pam (telles que celles qui utilisent gettyou loginverront leur umask défini via login.defs.

Lors d'une installation de Fedora 29 avec Gnome, j'ai constaté que les programmes lancés à partir du lanceur Gnome laissaient d'autres fichiers lisibles, 0022. Pam semble se reporter sur /etc/login.defs comme indiqué ci-dessus. Cependant, la modification du masque, 0077, n'a pas changé le comportement de Gnome. J'ai également dû éditer / etc / profile et / etc / bashrc - tous deux le remettant à 0022.

Ce serait bien si Fedora avait une place pour cela, mais les entrées dans / etc / profile et / etc / bashrc définissent le masque différemment pour les utilisateurs avec des ID supérieurs ou inférieurs à 200, il semble donc qu'un masque ne convient pas à tous.

Bien qu'il s'agisse d'un correctif pour l'instant, le problème n'est pas complètement résolu, car l'utilisateur gnome n'a toujours aucun moyen de définir son propre umask car il est appliqué aux applications qui s'exécutent à partir du lanceur gnome. Il semble que Gnome devrait avoir une option de configuration pour cet umask. (Peut-être que oui, mais je ne l'ai pas trouvé.)

J'ai la solution de contournement au moins sur Fedora 31:

sudo vi /etc/profile.d/umask.sh
umask <your_umask>

sudo vi /etc/login.defs
UMASK <your_umask>

sudo vi /usr/local/bin/systemd-user
/usr/lib/systemd/systemd --user

sudo chmod a+x /usr/local/bin/systemd-user

sudo vi /usr/lib/systemd/system/[email protected]
ExecStart=-/usr/local/bin/systemd-user