Como definir `umask` para toda a sessão do gnome?

10

Usando o Gnome 3.18. Compartilho arquivos entre outros membros da família, mas o umask padrão na minha distribuição (archlinux) é 0022. Portanto, todos os arquivos / diretórios criados não podem ser gravados em nosso grupo comum.

Eu tentei colocar umask 0002, /etc/profilemas a sessão do gnome ainda está usando 0022. Porém, ele está trabalhando para um shell bash de login.

Também tentei adicionar esta linha /etc/pam.d/system-auth: session required pam_umask.so umask=0002 Ela tem o mesmo efeito que a da /etc/profile. eu tentei

Se eu alterar o umask manualmente em um shell do terminal gnome, inicio um aplicativo, digamos gedit, e os arquivos criados por ele têm as permissões desejadas. Se eu iniciar o gedit nos menus do gnome, isso não acontece. Portanto, o meu problema é realmente definir o umask para a sessão do gnome, e não consigo encontrar onde fazê-lo.

EDIT (para responder ao comentário de Gilles): Estou usando o gdm 3.18 como o DM. Eu também tentei adicionar a linha pam_umask /etc/pam.d/gdm-launch-environment. Todos os outros gdm-*arquivos contém inclui de sessionpartir do system-autharquivo, para que eles não devem precisar de mais. Isso não muda nada.

/etc/login.defscontém UMASK 077, mas também USERGROUPS_ENAB yesque deve definir o umaskque quer 0077ou 0007para usuários cujas grupo primário é o nome de usuário.

O único arquivo que contém 022para umask in /etcé /etc/profilemas essa foi minha primeira tentativa.

Quanto a /etc/Xsession.d, não tenho esse diretório. Além disso, como o wayland agora é o servidor de exibição padrão, não tenho certeza se o umask deve ser definido como parte da inicialização do X, mesmo se eu ainda o estiver usando.

Christophe Drevet-Droguet
fonte
Qual gerenciador de exibição você usa? (Esse é o programa em que você digita seu nome de usuário e senha.) Gdm, lightdm, slim, xdm, kdm,…? Dependendo de como o Arch e seu DM estão configurados, tente adicionar um arquivo /etc/Xsession.dou um arquivo diferente /etc/pam.d(suponho que você queira definir esse sistema em todo o sistema). Ou talvez /etc/login.defs.
Gilles 'SO- stop be evil'
As duas respostas são válidas para ttyou sshlogins e são basicamente as mesmas, realmente (usando pam_umask). Eles não funcionam com a minha sessão de gnomo. Então, eu não posso dar a recompensa a ninguém. Não sei se isso é específico para o gnome no Xorg no archlinux. Vou testar com outras distribuições quando tiver algum tempo.
Christophe Drevet-Droguet
1
Há uma discussão semelhante no fórum archlinux tratar a questão: bbs.archlinux.org/viewtopic.php?id=207753 parece ser um bug no gdm ...
Acabei usando ACLs, que é uma maneira muito melhor de controlar permissões. Não há necessidade de alterar a máscara de permissões mais seguras padrão.
Christophe Drevet-Droguet

Respostas:

6

Alguns aplicativos Gnome são iniciados por systemd --user, caso em que umask é definido pelo systemd como 0022independentemente do valor configurado para pam_umask . Não conheço nenhuma solução alternativa, mas abri um problema no rastreador de problemas do systemd github. Esse problema também é relatado no bugzilla do Gnome .

O uso de conjunto de máscaras pam_umaskestá funcionando conforme o esperado para aplicativos que não são iniciados por systemd --user.

Uma solução alternativa é sugerida no bugzilla do Ubuntu  para substituir o serviço systemd em todos os aplicativos afetados.


Para investigar isso você mesmo

Você pode listar os processos em execução no seu sistema em um formato de árvore (processos pai / filho) usando:

pstree -Tapu

Encontre PIDs para: (1) a instância da sua sessão do systemd --user ; (2) um aplicativo lançado por ele , como o gedit, que aparecerá como processo filho no systemd --user ; e (3) um processo em sua sessão não iniciado pelo systemd --user .

Compare umasks relatadas no procfs :

grep Umask /proc/<pid>/status

systemd --user propriamente dito (1) e processos não iniciados por ele (3) devem ter o umask correto, definido por pam_umask . Os processos iniciados pelo systemd --user (2) terão umask de 0022.

sebasth
fonte
3

O problema é o mencionado por Sebasth. Eu tentei muitas coisas, mas depois encontrei uma solução alternativa que consiste em substituir a UMask (por usuário) do dbus:

$ systemctl --user edit dbus

No arquivo que é aberto, basta escrever:

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

O arquivo é salvo em .config / systemd / user / dbus.service.d / override.conf e substitui o umask padrão do dbus, que presumo ser herdado do systemd --user, pois o dbus é iniciado por ele. Faça logout e faça login novamente e os aplicativos gnome devem usar o umask especificado. Apenas uma solução alternativa, mas funciona para mim.

egdoc
fonte
2

Em vez disso, altere a opção para a qual umaskvocê pode usar , com esse usuário e grupo, as mesmas permissões que a maneira clássica do unix de compartilhar pastas.usergroupspam_umask

# /etc/pam.d/login or
# /etc/pam.d/common-session or system-auth
session optional pam_umask.so usergroups
xae
fonte
1
Se o usuário não for root e o nome de usuário for o mesmo que o nome do grupo principal , os bits do grupo umask serão definidos como os bits do proprietário (exemplos: 022 -> 002, 077 -> 007).
Christophe Drevet-Droguet
Eu uso o grupo principal como o grupo de compartilhamento. Com grupos de usuários, os arquivos serão criados com esse grupo de usuários por padrão e não editáveis ​​por outros usuários.
Christophe Drevet-Droguet
1
No entanto, vejo uma maneira: posso usar grupos de usuários e um grupo secundário comum e, na árvore compartilhada, adicionar um bit "set group" para forçar esse grupo comum em todos os arquivos e pastas criados. Enfim, vou tentar no meu PC mais tarde. Não tenho certeza se o gnome se importará com isso de qualquer maneira, porque sempre leva 0022 como uma umask, não importa o que esteja funcionando para sessões tty.
Christophe Drevet-Droguet
1

Para definir o padrão umask em todo o sistema, você deverá habilitá-lo em primeiro lugar, o que é bastante explicado aqui:

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

O link acima é para debian e ubuntu, mas o mesmo para todos os outros sistemas linux.

Para habilitá-lo umask (que talvez já esteja no lugar), você precisa adicionar uma linha a /etc/pam.d/common-session:

session optional pam_umask.so

Depois de ativado, você pode configurá-lo em:

/etc/login.defs

Vejo que você já encontrou esse arquivo, então tudo o que você precisa fazer é definir:

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

E configure UMASK para 0002 ou o que você quiser.

Isso definirá o valor padrão em todo o sistema, o que significa que todos os usuários terão o umask a partir daí, a menos que não tenham definido especificamente o contrário em seus perfis .profile ou .bashrc

ostendali
fonte
Obrigado pela sua resposta. Vou ter que tentar isso. Não sou tão otimista porque já tentei este módulo PAM com um parâmetro embutido "umask = 0002" e não funcionou (para o Gnome, funcionou para outros shells de login). Vou tentar sua sugestão.
Christophe Drevet-Droguet
você tentou módulo pam para system-auth não common-auth :-)
ostendali
3
É apenas uma questão de escolha de distribuição dos nomes dos arquivos. Eu sei que o debian usa common-*para configurações comuns. Arch, como RedHat, usa um system-autharquivo para isso. Enfim, tentei sua sugestão de adicionar session optional pam_umask.soe UMASK 002entrar /etc/login.defsComo eu esperava, e assim como pam_umask.so umask=0002funcionou para uma loginsessão tty (ou através do SSH), mas o Gnome definiu uma 0022umask como sempre. O Gnome deve usar uma configuração interna umask, ou o archlinux está usando uma… tentarei outra distribuição para ver se o problema também ocorre.
Christophe Drevet-Droguet
1

Para a sessão de login: adicione umask 0002ao seu $HOME/.profile(ou /etc/profile).

Para a sessão do Gnome: adicione umask 0002ao seu$HOME/.gnomerc

ctruta
fonte
1

EDIT: Para que o systemd defina o umask da sessão do gnome, criei um arquivo umask.conf em /etc/systemd/system/display-manager.service.d/ com as seguintes linhas:


[Service]
UMask=0002

Depois de reiniciar a máquina, isso agora permite que todos os processos abaixo user.sliceestejam em conformidade com o umask que você deseja. O logout não foi suficiente para que as alterações ocorram, portanto, aconselho reiniciar a máquina antes de executar os testes no processo umasks.

Informações adicionais:

  • SO: CentOS7.4
  • DE: Gnome3
jamalm
fonte
3
Se estiver funcionando, um arquivo como /etc/systemd/system/gdm.service.d/umask.confcontendo apenas [Service]\nUMask=0002deve ser suficiente.
Christophe Drevet-Droguet
E de fato faz! apenas testei lá. minha pasta / etc / systemd / system / contém um link simbólico para gdm.service, então eu criei um display-manager.service.d / umask.conf e adicionei a linha, funcionou perfeitamente, atualizando a resposta para incluí-la. @ ChristopheDrevet-Droguet
jamalm
0

Só queria acrescentar que as pam_umaskpáginas de manual fornecem algumas informações muito boas para ajudá-lo a descobrir de onde vem a sua umask. Especificamente:

pam_umask é um módulo PAM para definir a máscara de criação do modo de arquivo do ambiente atual. O umask afeta as permissões padrão atribuídas aos arquivos recém-criados.

O módulo PAM tenta obter o valor umask dos seguintes locais na seguinte ordem:

·   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

Como alguém afirmou, você deve configurá-lo no common-sessionarquivo no diretório /etc/pam.d.

Observe que os logons que não usam pam (como aqueles que usam gettyou loginterão o umask definido via login.defs.

Charles Addis
fonte
0

Em uma instalação do Fedora 29 com o Gnome, descobri que os programas lançados a partir do iniciador do Gnome deixaram outros arquivos legíveis, 0022. Pam aparentemente adia para /etc/login.defs como observado acima. No entanto, editar a máscara lá, 0077, não mudou o comportamento do Gnome. Eu também tive que editar o / etc / profile e o / etc / bashrc - ambos os quais estavam definindo-o como 0022.

Seria bom se o Fedora tivesse um lugar para isso, mas as entradas em / etc / profile e / etc / bashrc definem a máscara de maneira diferente para usuários com IDs acima ou abaixo de 200, então parece que uma máscara não serve para todos.

Embora essa seja uma correção por enquanto, o problema não está completamente resolvido, pois o usuário do gnome ainda não tem como definir sua própria umask, pois é aplicada a aplicativos executados a partir do iniciador do gnome. Parece que o Gnome deve ter uma opção de configuração para esse umask. (Talvez sim, mas não o encontrei.)

user244488
fonte
0

Eu tenho a solução alternativa pelo menos no 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
Charles
fonte