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

Question

Como você pode ler, por exemplo aqui , 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. Em suma, se você começar, digamos, amarok, e tocar alguma música, você ouvirá o som até mudar para outro usuário ou TTY, onde terá apenas o prompt de login. Isso porque a sessão ativa ficou inativa.

Sei que você pode simplesmente adicionar um usuário (ou usuários) a um grupo específico, neste caso "áudio", 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 fique ligado a maior parte do tempo, então apenas bloqueio a tela. Mas quando eu bloqueio a tela, a sessão ativa fica inativa e o amarok pára de tocar. E sim, a tela deve estar bloqueada e não apenas desativada.

EDITAR:

Eu não acho que isso importe qual distro eu estou usando, porque se houver systemd on board, 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 de branch experimental, e agora é a versão 219-9.

    

Answer 1

O Pulseaudio é iniciado via xdg autostart, que pode ser encontrado em ~/.config/autostart/ . Há um arquivo chamado pulseaudio.desktop e, nesse arquivo, alterei a linha padrão exec para essa:

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

Quando eu faço o login no sistema, o processo pulseaudio é assim:

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

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

    

Answer 2

Não tenho certeza, 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 jogaria sem desmarcar isso, então o consolekit não adicionará dispositivos de som em seu banco de dados e não gerenciará a ACL em dispositivos de som

    

Answer 3

Deixe-me dizer que eu 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 é executado. Use systemd para forçar o amarok a ser executado 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 de hoje.

    

Answer 4

Que tal rodar o player no vnc framebuffer? Na hortelã 17 ...

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

Você usaria o VNC para visualizar a área de trabalho conforme descrito no link