Existe uma maneira de definir permissões para que um processo possa usar um dispositivo específico?

12

Como você pode ler, por exemplo , aqui , o logind, que faz parte do systemd, pode definir permissões para alguns dispositivos para sessões do usuário. Há também um vídeo mostrando como esse tipo de comportamento funciona na prática. Resumindo, se você começar, digamos, amarok, e tocar alguma música, ouvirá o som até mudar para outro usuário ou TTY, onde você terá apenas o prompt de login. Isso ocorre porque a sessão ativa ficou inativa.

Eu sei que você pode simplesmente adicionar um usuário (ou usuários) a um grupo específico, neste caso "audio", e isso 'corrigirá' esse problema, mas estou me perguntando se há outra solução. O que eu realmente quero é definir algumas permissões para o processo para que ele possa usar a placa de som o tempo todo, mesmo quando todos os usuários tiverem suas sessões bloqueadas.

Isso é possível? Estou perguntando, porque muitas vezes ouço a música e realmente não preciso que meu monitor esteja ligado a maior parte do tempo, então apenas bloqueio a tela. Mas quando bloqueio a tela, a sessão ativa fica inativa e o amarok para de tocar. E sim, a tela deve estar bloqueada e não apenas desligada.

EDITAR:

Eu não acho que isso importe qual distro eu estou usando, porque se houver systemd a bordo, seria exatamente o mesmo problema. De qualquer forma, estou usando o debian sid, mas alguns pacotes como systemd, udev (e algumas dependências) são do ramo experimental, e agora é a versão 219-9.

systemd session logind

— Mikhail Morfikov
fonte

1

Possivelmente correr nohup program_x & ; disownpoderia ajudar. Ou usando a tela

— JustMe

Mas o processo funciona muito bem. Quando bloqueio a tela, ela não pode mais usar a placa de som, pelo menos até desbloquear a tela.

— Mikhail Morfikov

Você já tentou usar loginctl enable-lingera conta?

— Spuk

De acordo com o wiki do arch:

The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect.

Isso não diz respeito a uma sessão de usuário inativo, porque systemd --userestá presente o tempo todo.

— Mikhail Morfikov

Normalmente, deixo minha música tocando no meu laptop Fedora 21 enquanto durmo depois de bloqueá-lo. Portanto, não acho que bloquear a tela do computador marque uma sessão como inativa apenas por causa do systemd.

— Bratchley 17/05

1

Não sei qual versão / sabor do Linux você está usando, mas parece que as ACLs para dispositivos de som são controladas pelo ConsoleKit por meio das regras do udev. No meu host Debian, vejo algo como abaixo em /lib/udev/rules.d/70-udev-acl.rules

# sound devices
SUBSYSTEM=="sound", TAG+="udev-acl"

Eu gostaria de desmarcar isso, para que o consolekit não adicione dispositivos de som ao banco de dados e não gerencie a ACL em dispositivos de som

— VenkatC
fonte

Eu verifiquei na minha área de trabalho comentando acima da linha e após a reinicialização. Não há mais a gestão ACL para dispositivos de som e posso tocar músicas com a minha tela bloqueada

— VenkatC

Eu atualizei a pergunta. Agora, o consolekit é algo obsoleto - você pode ler mais sobre isso aqui freedesktop.org/wiki/Software/ConsoleKit , e meu sistema não o usa. O Logind é um substituto para ele, e basicamente faz a mesma coisa. Tentei comentar a linha que você me deu e, após a reinicialização, meu sistema não vê nenhuma placa de som. Mesmo que funcionasse e funcionasse bem, não acho que usaria essa solução - é porque seria a mesma coisa que adicionar um usuário ao grupo de áudio, pelo menos a vejo dessa maneira.

— Mikhail Morfikov

Obrigado, olhei para os detalhes do logind e sim, ele está fazendo coisas semelhantes. Ele está procurando o uaccess TAG do udev para identificar dispositivos a serem gerenciados e está em /lib/udev/rules.d/70-uaccess.rules. Está tudo se resumindo às permissões básicas do unix, na minha opinião, você tem essas opções 1) remova a etiqueta da placa de som via udev, para que o logind não gerencie o dispositivo de áudio e a tela de bloqueio, alternando usuários - não altere as permissões dos dispositivos de som. você pode definir perms como você gosta 2) você pode simplesmente encontrar binário amarok e defini-lo do grupo a ser áudio e setgid-lo, por isso é grupo efetivo se torna áudio

— VenkatC

Eu verifiquei a segunda solução, mas infelizmente não funciona. I definido audio grouppara o binário amarok, e as permissões são os seguintes: -rwxr-sr-x, mas quando eu tento iniciar amarok como um usuário regular, eu recebo este erro:

QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. unnamed app(24333): KUniqueApplication: Cannot find the D-Bus session server:  "Unable to autolaunch when setuid"

— Mikhail Morfikov

hmm, parece que a execução de programas setuid na GUI parece muito complicada e bloqueada por razões de segurança, por exemplo: gtk.org/setuid.html . Vou pesquisar mais e informar você, isso é bom - aprender coisas novas!

— VenkatC

0

Deixe-me dizer que sei pouco sobre áudio no desktop Linux. Mea Culpa, se isso não ajudar.

Eu definiria as permissões de grupo do dispositivo de áudio:

chgrp audio <dev-path>
chmod g+rw <dev-path>

ao grupo em que o amarok executa. Use systemd para forçar a execução do amarok nesse grupo. Primeiro copie o arquivo amarok systemd para / etc / systemd / user / e modifique-o:

[Service]
Group=audio

(isso é uma modificação, não o arquivo inteiro).

Mas pode haver uma resposta mais "sofisticada" devido às múltiplas camadas que são o sistema de áudio Linux atual.

— Otheus
fonte

1

Quanto a chgrp audio- todos os dispositivos em / dev / snd / já têm o audiogrupo, mas isso não deve importar quando você usa o pulseaudio, e é esse o caso. Quando se trata do serviço do systemd, tentei, mas recebi o seguinte erro:

Failed at step GROUP spawning /usr/bin/amarok: Operation not permitted. amarok.service: main process exited, code=exited, status=216/GROUP

e não acho que possa alterar esses grupos como um usuário comum. Eu tenho outro serviço que requer alteração de grupo, mas é um daemon de sistema normal e funciona muito bem. `

— Mikhail Morfikov

O serviço Amarok não é iniciado pela raiz? É possível que o Amarok precise de outras permissões de grupo para outras invasões. Pena que não é tão fácil.

— Otheus

É apenas um tocador de música. :)

— Mikhail Morfikov

0

Que tal executar o player no vnc framebuffer? Na casa da moeda 17 ...

# apt search vfb
p   xvfb                            - Virtual Framebuffer 'fake' X server
p   xvfb:i386                       - Virtual Framebuffer 'fake' X server

Você usaria o VNC para exibir a área de trabalho, conforme descrito em https://en.wikipedia.org/wiki/Xvfb

— smokes2345
fonte

Eu li o Usage scenarioslink no wiki e acho que nenhum deles se aplica aqui. O processo (amarok) só precisa de algumas permissões, e eu não tenho idéia de como defini-las, se isso for possível.

— Mikhail Morfikov

Que permissões você acha que precisa? Eu duvido muito que o systemd esteja alterando as permissões nos dispositivos apenas porque você muda o tty e, se isso acontecer, farei o possível para evitá-lo como a praga de agora em diante. Também não sei se isso ajudará você, não testei, mas é a única ideia que tenho que tem chance de funcionar. Além disso, os usuários têm permissões, não processos.

— Smokes2345

Basta ler o primeiro link da pergunta.

— Mikhail Morfikov

0

O Pulseaudio é iniciado via inicialização automática do xdg, que pode ser encontrada em ~/.config/autostart/. Há um arquivo chamado pulseaudio.desktop, e nesse arquivo eu mudei a execlinha padrão para esta:

Exec=/usr/bin/sg audio -c "pulseaudio -D"

Quando eu entro no sistema, o processo pulseaudio fica assim:

$ ps -eo user,group,args | grep pulse
morfik   audio    pulseaudio -D
morfik   audio    /usr/lib/pulseaudio/pulse/gconf-helper

E agora eu sou capaz de ouvir a música o tempo todo. Eu acho que essa é a solução que eu estava procurando.

— Mikhail Morfikov
fonte