Esiste un modo per impostare le autorizzazioni in modo che un processo possa utilizzare un dispositivo specifico?


12

Come puoi leggere, ad esempio qui , logind, che fa parte di systemd, può impostare autorizzazioni per alcuni dispositivi per le sessioni utente. C'è anche un video che mostra come questo tipo di comportamento funziona nella pratica. In breve, se inizi, diciamo, amarok e suoni un brano, sentirai il suono fino a quando non passerai a un altro utente o TTY in cui hai solo il prompt di accesso. Questo perché la sessione attiva è diventata inattiva.

So che puoi semplicemente aggiungere un utente (o utenti) a un gruppo specifico, in questo caso "audio", e questo "risolverà" questo problema, ma mi chiedo se c'è un'altra soluzione. Quello che voglio davvero è impostare alcune autorizzazioni per il processo in modo che possa usare sempre la scheda audio, anche quando tutti gli utenti hanno le sessioni bloccate.

È possibile? Lo chiedo perché ascolto spesso la musica e non ho davvero bisogno che il mio monitor sia acceso per la maggior parte del tempo, quindi blocco lo schermo. Ma quando blocco lo schermo, la sessione attiva diventa inattiva e Amarok smette di giocare. E sì, lo schermo dovrebbe essere bloccato e non solo spento.

MODIFICARE:

Non penso che sia importante quale distro sto usando perché se ci fosse systemd a bordo, sarebbe lo stesso identico problema. Ad ogni modo, sto usando debian sid, ma alcuni pacchetti come systemd, udev (e alcune dipendenze) provengono da un ramo sperimentale, e ora è la versione 219-9.


1
Forse correre nohup program_x & ; disownpotrebbe aiutare. O usando lo schermo
JustMe

Ma il processo funziona bene. Quando blocco lo schermo, non è più possibile utilizzare la scheda audio, almeno fino a quando non sblocco lo schermo.
Mikhail Morfikov

Hai provato a utilizzare loginctl enable-lingerper l'account?
spuk,

Secondo l'arch wiki: 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.ciò non riguarda una sessione utente inattiva perché systemd --userè sempre presente.
Mikhail Morfikov,

Lascio regolarmente la mia musica in riproduzione sul mio laptop Fedora 21 mentre dormo dopo averlo bloccato. Quindi non penso che il blocco dello schermo del tuo computer dovrebbe contrassegnare una sessione come inattiva solo a causa di systemd.
Bratchley,

Risposte:


1

Non sono sicuro di quale versione / sapore di Linux stai usando, ma sembra che gli ACL per i dispositivi audio siano controllati da ConsoleKit tramite regole udev. Sul mio host Debian, vedo qualcosa di simile in basso in /lib/udev/rules.d/70-udev-acl.rules

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

Giocherei senza deselezionarlo, quindi consolekit non aggiungerà dispositivi audio nel suo database e non gestirà ACL su dispositivi audio


Ho verificato sul mio desktop commentando la riga sopra e dopo il riavvio. Niente più gestione ACL per dispositivi audio e posso riprodurre brani con lo schermo bloccato
VenkatC,

Ho aggiornato la domanda. Ora consolekit è roba obsoleta: puoi leggere di più qui freedesktop.org/wiki/Software/ConsoleKit e il mio sistema non lo usa. Logind è un sostituto, e sostanzialmente fa la stessa cosa. Ho provato a commentare la linea che mi hai dato e dopo il riavvio, il mio sistema non vede alcuna scheda audio. Anche se ha funzionato e questo ha funzionato bene, non penso che userei questa soluzione - è perché sarebbe la stessa cosa di aggiungere un utente al gruppo audio, almeno lo vedo in questo modo.
Mikhail Morfikov

Grazie, ho guardato i dettagli del logind e sì, sta facendo cose simili. È alla ricerca di udev TAG 'uaccess' per identificare i dispositivi da gestire ed è in /lib/udev/rules.d/70-uaccess.rules. Tutto dipende dalle autorizzazioni unix di base, secondo me hai queste opzioni 1) rimuovi il tag della scheda audio tramite udev, quindi logind non gestisce il dispositivo audio e blocca lo schermo, cambiando gli utenti - non cambierà le autorizzazioni dei dispositivi audio. potresti impostare permanenti come preferisci 2) potresti semplicemente trovare il binario amarok e impostare il suo gruppo come audio e impostarlo, quindi il suo gruppo efficace diventa audio
VenkatC

Ho controllato la seconda soluzione, ma sfortunatamente non funziona. Ho impostato audio groupil binario di Amarok e le autorizzazioni sono le seguenti -rwxr-sr-xQDBusConnection: 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"
:,

hmm, sembra che l'esecuzione di programmi setuid nella GUI sia complicata e bloccata per motivi di sicurezza, ad esempio: gtk.org/setuid.html . Cercherò di più e ti farò sapere, questa è roba buona - imparare cose nuove!
VenkatC,

0

Lasciami dire che so poco sull'audio sul desktop Linux. Mea Culpa se questo non aiuta.

Vorrei impostare le autorizzazioni di gruppo del dispositivo audio:

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

al gruppo in cui è in esecuzione Amarok. Utilizzare systemd per forzare l'esecuzione di Amarok in quel gruppo. Per prima cosa copia il file systemd di amarok in / etc / systemd / user / e modificalo:

[Service]
Group=audio

(è una modifica, non l'intero file).

Ma potrebbe esserci una risposta più "sofisticata" a causa dei molteplici livelli che sono il sistema audio Linux di oggi.


1
Per quanto riguarda chgrp audio- tutti i dispositivi sotto / dev / snd / hanno già il audiogruppo, ma questo non dovrebbe importare quando usi pulseaudio, e questo è il caso. Quando si tratta del servizio di systemd, l'ho provato, ma ho riscontrato il seguente errore: Failed at step GROUP spawning /usr/bin/amarok: Operation not permitted. amarok.service: main process exited, code=exited, status=216/GROUPe non credo di poter cambiare questi gruppi come utente normale. Ho un altro servizio che richiede il cambio di gruppo, ma è un normale demone di sistema e funziona perfettamente. `
Mikhail Morfikov,

Il servizio Amarok non è avviato da root? È possibile che Amarok abbia bisogno di altre autorizzazioni di gruppo per altri puproses. Peccato che non sia così facile.
Otheus,

È solo un lettore musicale. :)
Mikhail Morfikov

0

Che ne dici di far funzionare il lettore in framebuffer vnc? In Mint 17 ...

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

VNC verrà utilizzato per visualizzare il desktop come descritto in https://en.wikipedia.org/wiki/Xvfb


Ho letto il Usage scenarioslink nel wiki e non credo che nessuno di questi si applichi qui. Il processo (amarok) ha solo bisogno di alcune autorizzazioni e non ho idea di come impostarle, se possibile.
Mikhail Morfikov,

Quali autorizzazioni ritieni di aver bisogno? Dubito fortemente che systemd stia cambiando le autorizzazioni sui dispositivi solo perché si cambia tty e se lo farò, farò del mio meglio per evitarlo come la peste d'ora in poi. Non so che questo ti aiuterà, non l'ho provato, ma è l'unica idea che ho che abbia una possibilità di lavorare. Inoltre, gli utenti hanno autorizzazioni, non processi.
fuma2345

Basta leggere il primo link nella domanda.
Mikhail Morfikov,

0

Pulseaudio viene avviato tramite l'avvio automatico xdg, che si trova sotto ~/.config/autostart/. C'è un file chiamato pulseaudio.desktope in quel file ho cambiato la execlinea di default con questa:

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

Quando accedo al sistema, il processo pulseaudio è simile al seguente:

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

E ora sono in grado di ascoltare la musica tutto il tempo. Penso che questa sia la soluzione che stavo cercando.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.