Bug 499926
Summary: | pulseaudio starts twice on login if started in system mode before login | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rudd-O DragonFear <rudd-o> |
Component: | pulseaudio | Assignee: | Lennart Poettering <lpoetter> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | h.reindl, lkundrak, lpoetter, mads, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-05-10 13:21:27 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rudd-O DragonFear
2009-05-09 02:05:13 UTC
Uh. In Fedora we install PA as session daemon. We don't really support running it as system daemon, for a number of reasons. *** This bug has been marked as a duplicate of bug 461546 *** > Uh. In Fedora we install PA as session daemon. > We don't really support running > it as system daemon, for a number of reasons. Ater some months ago since https://bugzilla.redhat.com/show_bug.cgi?id=461546 the question is the same: why? I have running it as systemwide-daemon and it works It works for background-services as for local users The only problem is i have to login local per gui After the login i have to call the following script (no matter locally or even in ssh-session, it neeeds any local gui-login) After that you can logout, change the local user, switch to tty or whatever you want and everybody has sound, can use "sonata" to pause mpd and hear some stream or whatever. I think it would be important to get pulseaudio working systemwide as default and solve the couple of problems in the affected apllications, what you do with per-user is a dirty workaround but never the final-solution for a DAEMON #!/bin/bash killall pulseaudio 2> /dev/null /sbin/service pulsed restart 2> /dev/null sleep 1 /sbin/service mpd restart 2> /dev/null /usr/bin/mpc play (In reply to comment #2) > > Uh. In Fedora we install PA as session daemon. > > We don't really support running > > it as system daemon, for a number of reasons. > > Ater some months ago since https://bugzilla.redhat.com/show_bug.cgi?id=461546 > the question is the same: why? It's mostly due to security, but also because all the policy logic is intended to be per-user. For security reasons we need to disable quite a bit functionality if we cannot trust the connecting user. SHM memory transfer is one of those features. Then, stuff like BT and so on relies on a proper session to be available, because auth creds are user-specific data. And so on, and so on. The system mode is intended to be used on systems like thin clients, where there is no proper local user. It's not intended to be use on normal desktops. If you want to shoot yourself in the foot, you are welcome to, but please, don't ask me to pull the trigger for you. If you want to use PA in system mode, do so, but please don't ask us to support that in Fedora. Lennart, I understand what the motivations were, and I am completely on board with disabling e.g. SHM, but not the BT functionality. For that, you CAN trust the pulse user which is system-created and with al the PA safeguards, not likely to be invaded by regular users and, at best, the worst thing that could happen is that the BT device gets captured by PA, which was the point of it all in the beginning, right? Besides, what do YOU care if I run PA in system mode? As you have said it well, it's my security problem, not yours, right? So why is the system bus denying access to pulse when it wants to access the BlueZ stack? It should be ALLOWED at least for the system pulse user, and THAT won't affect PA or weaken system security when runnning it as user, as per the default. So really, there is NO reason to disallow access to the BT stack for the pulse user. Lennart, I'm not asking you to *support* PA in system mode. All I'm asking is for you guys to show us a significant minority of users a bit of consideration and ship PA with access to the BT bus endpoint. If you do that, there is no net negative effect for the supported user-mode configuration anyway, so not doing it is really not a "security consideration" but more of a whim. (In reply to comment #4) > Lennart, > > I understand what the motivations were, and I am completely on board with > disabling e.g. SHM, but not the BT functionality. For that, you CAN trust the > pulse user which is system-created and with al the PA safeguards, not likely to > be invaded by regular users and, at best, the worst thing that could happen is > that the BT device gets captured by PA, which was the point of it all in the > beginning, right? I already pointed out elsewhere that the BT issue is a D-Bus permission issue that needs to be fixed in BlueZ, not PA. > Besides, what do YOU care if I run PA in system mode? I don't, just read what I wrote about "shooting yourself in the foot". > As you have said it > well, it's my security problem, not yours, right? So why is the system bus > denying access to pulse when it wants to access the BlueZ stack? Don ask me, ask the bluez packagers. |