gnomeセッション全体に「umask」を設定するにはどうすればよいですか？

Gnome 3.18の使用。他の家族とファイルを共有していますが、私のディストリビューション（archlinux）のデフォルトのumaskは0022です。したがって、作成されたすべてのファイル/ディレクトリは、私たちの一般的なグループに書き込み可能ではありません。

入れようとしましumask 0002た/etc/profileが、gnomeセッションはまだ使用してい0022ます。ただし、ログインbashシェルでは機能します。

私もこの行を追加しようとしました/etc/pam.d/system-auth： session required pam_umask.so umask=0002 これはと同じ効果があり/etc/profileます。私は試した

gnome-terminalシェルでumaskを手動で変更した場合、geditなどのアプリケーションを起動して、作成したファイルに必要な権限が付与されます。gnomeメニューからgeditを起動しても、起動しません。だから私の問題は本当にgnomeセッションのumaskを設定することであり、それをどこで行うべきかを見つけることができません。

編集（Gillesのコメントに答えるため）：DMとしてgdm 3.18を使用しています。また、pam_umask行をに追加しようとしました/etc/pam.d/gdm-launch-environment。他のすべてのgdm-*ファイルにはsession、system-authファイルからのインクルードが含まれているため、追加のファイルは必要ありません。何も変わりません。

/etc/login.defsが含まれますUMASK 077が、プライマリグループがユーザー名であるユーザーまたはユーザーのいずれかにUSERGROUPS_ENAB yes設定する必要があります。umask00770007

022でumask が含まれている唯一のファイルです/etcが/etc/profile、それは私の最初の試みでした。

に関しては/etc/Xsession.d、私はこのディレクトリを持っていません。その上、ウェイランドがデフォルトのディスプレイサーバーになっているので、自分でまだ使用している場合でも、umaskをX初期化の一部として設定する必要があるかどうかはわかりません。

一部のGnomeアプリケーションはによって起動されます。systemd --userこの場合0022、pam_umaskの設定値に関係なく、umaskはsystemdによってに設定されます。私は回避策を認識していませんが、 systemd github issue trackerで問題を開きました。この問題はGnome bugzillaでも報告されています。

を使用してUmaskセットを使用するpam_umaskと、で起動されないアプリケーションで期待どおりに機能しますsystemd --user。

Ubuntu Bugzillaでは  、影響を受けるすべてのアプリケーションにsystemdサービスのオーバーライドを配置するための1つの回避策が提案されています。

これを自分で調査するには

次のコマンドを使用して、システムで実行中のプロセスをツリー形式（親/子プロセス）で一覧表示できます。

pstree -Tapu

次のPIDを見つけます：（1）systemd --userのセッションのインスタンス。（2） systemd --userに子プロセスとして表示されるgeditなどのアプリケーションによって起動されたアプリケーション。そして（3）あなたのセッションでの処理にsystemd --userによって起動ません。

procfsで報告されたumaskを比較します。

grep Umask /proc/<pid>/status

systemd --user自体（1）およびそれによって起動されないプロセス（3）には、pam_umaskによって設定された正しいumaskが必要です。systemd --user （2）によって起動されたプロセスのumaskはになり0022ます。

問題はセバストが述べたものです。多くのことを試しましたが、dbusの（ユーザーごとの）UMaskを上書きするという回避策を見つけました。

$ systemctl --user edit dbus

開かれるファイルに、次のように記述します。

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

ファイルは.config / systemd / user / dbus.service.d / override.confに保存され、dbusが起動するため、systemd --userから継承されたと想定されるdbusのデフォルトのumaskを上書きします。ログアウトして再度ログインするだけで、gnomeアプリケーションは指定されたumaskを使用する必要があります。単なる回避策ですが、私にとってはうまくいきます。

代わりにumask、のusergroupsオプションを使用することができます。pam_umaskこのユーザーとグループには、フォルダを共有する従来のUNIXの方法と同じ権限があります。

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

システム全体でデフォルトのumaskを設定するには、最初にそれを有効にする必要があります。

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

上記のリンクはdebianとubuntu用ですが、他のすべてのLinuxシステムでも同じです。

umaskを有効にするには（おそらくすでに配置されています）、次の行を追加する必要があります/etc/pam.d/common-session。

session optional pam_umask.so

有効にすると、次のように設定できます。

/etc/login.defs

私はあなたがすでにこのファイルを見つけたので、あなたがする必要があるのは設定することです：

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

そして、UMASKを0002またはその他の任意の値に設定します。

これにより、システム全体でデフォルト値が設定されます。つまり、.profile または.bashrcで特に設定しない限り、すべてのユーザーがそこからumaskを取得します。

ログインセッションの場合：（または）に追加umask 0002します。$HOME/.profile/etc/profile

GNOMEセッションの場合：追加しumask 0002、あなたに$HOME/.gnomerc

編集：gnomeセッションのumaskを設定するためにsystemdを取得するために、/ etc / systemd / system / display-manager.service.d /の下に次の行を含むumask.confファイルを作成しました。

[Service]
UMask=0002

マシンを再起動した後、これにより、すべてのプロセスuser.sliceが必要なumaskに準拠するようになります。ログアウトは変更を行うのに十分ではなかったので、プロセスumaskでテストを実行する前にマシンを再起動することをお勧めします。

 追加情報：

• OS：CentOS7.4
• DE：Gnome3

pam_umaskマンページがあなたのumaskがどこから来ているのかを理解するのに役立つかなり良い情報を提供することを追加したかっただけです。具体的には：

pam_umaskは、現在の環境のファイルモード作成マスクを設定するPAMモジュールです。umaskは、新しく作成されたファイルに割り当てられているデフォルトの権限に影響します。

PAMモジュールは、次の場所から次の順序でumask値を取得しようとします。

·   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

誰かが述べたように、これcommon-sessionはディレクトリ内のファイルで設定する必要があります/etc/pam.d。

pamを使用しないログイン（umask を使用する、gettyまたは使用するlogin予定のログインなど）に注意してくださいlogin.defs。

Gnomeを使用したFedora 29のインストールで、Gnomeランチャーから起動されたプログラムが他のファイルを読み取り可能なままにしていたことを発見しました。Pamは明らかに上記のように/etc/login.defsに依存しています。ただし、そこでマスクを編集した0077では、Gnomeの動作は変更されませんでした。/ etc / profileと/ etc / bashrcも編集する必要があり、どちらも0022に戻していました。

Fedoraにこのための場所が1つあればいいのですが、/ etc / profileと/ etc / bashrcのエントリは、200以上または以下のIDを持つユーザーに対して異なるマスクを設定するため、1つのマスクがすべてに当てはまるわけではないようです。

これは現在のところ修正ですが、gnomeランチャーから実行されるアプリケーションに適用されるため、gnomeユーザーは自分のumaskを設定する方法がないため、問題は完全には解決されません。Gnomeにはそのumaskの構成オプションが必要です。（たぶんそうですが、見つかりませんでした。）

私は少なくとも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/user@.service
ExecStart=-/usr/local/bin/systemd-user