Bug 489999

Summary: X server to isolate alsa interface
Product: [Fedora] Fedora Reporter: Sergei LITVINENKO <sergei.litvinenko>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: sergei.litvinenko, xgl-maint
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-08 17:50:11 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 Sergei LITVINENKO 2009-03-12 20:04:56 UTC
Description of problem:

As quick as X server is started, alsa is not accessible. So, application can not access to alsa. Pulseaudio start, but do not work.
As quick as X is finished, alsa is accessible for applications again...


Version-Release number of selected component (if applicable):

xorg-x11-server-Xorg-1.6.0-9.fc11.i586

alsa-tools-1.0.19-3.fc11.i586
alsa-plugins-pulseaudio-1.0.18-3.fc11.i586
alsa-utils-1.0.19-4.fc11.i586
alsa-lib-1.0.19-3.fc11.i586

kernel-2.6.29-0.218.rc7.git2.fc11.i586


How reproducible:
100%

Steps to Reproduce:
1. boot rawhide in runlevel 3
2. Login from remote PC by ssh
2. check is alsa accessible `alsamixer -c 0` in ssh session (accessible)
3. start 'X' by `startx` or directly by `/usr/bin/X` as user in rawhide console
4. check is alsa accessible `alsamixer -c 0` in ssh session (is not)
5. stop 'X'
  
Actual results:

1. pulseaudio can not start correct:
tail /var/log/messages
Mar 12 21:43:56 rawhide pulseaudio[2741]: module-alsa-card.c: Card '0' doesn't exist...

2. alsamixer can not access to hw:
[sergeil@rawhide ~]$ alsamixer -c 0
wrong -c argument '0'

Expected results:

pulseaudio start and work
alsamixer or any other application start and work correct with alsa.

Additional info:

1. System is fully updated till right now.
2. I has tested it as user, root, with selinux enabled, with selinux disabled. It is the same...

3. Environment: KVM 
qemu-kvm -localtime -std-vga -hda rawhide.img -boot c -net nic,macaddr=52:54:00:12:34:FB,model=virtio -net tap -soundhw es1370 -m 1024

KVM version: 

etherboot-roms-kvm-5.4.4-5.fc10.i386
kvm-74-10.fc10.i386

Comment 1 Sergei LITVINENKO 2009-03-15 13:53:49 UTC
Aftef update:

1. root can use alsa even X is started.
2. user can use alsa if it is permitted read/write /dev/snd/*

3. after X is finished, user can use alsa, even if attributes of /dev/snd/* are standard

[root@rawhide snd]# ll /dev/snd
итого 0
crw-rw----+ 1 root audio 116, 8 Мар 15 13:32 controlC0
crw-rw----+ 1 root audio 116, 4 Мар 15 13:32 midiC0D0
crw-rw----+ 1 root audio 116, 7 Мар 15 13:52 pcmC0D0c
crw-rw----+ 1 root audio 116, 6 Мар 15 15:47 pcmC0D0p
crw-rw----+ 1 root audio 116, 5 Мар 15 13:32 pcmC0D1p
crw-rw----+ 1 root audio 116, 3 Мар 15 13:32 seq
crw-rw----+ 1 root audio 116, 2 Мар 15 13:32 timer

Comment 2 Sergei LITVINENKO 2009-03-21 12:42:24 UTC
Some add.

After login in text console (not by SSH), user sergeil is permitted to use alsa and getfact show right permissions for alsa devices.

[sergeil@rawhide ~]$ getfacl /dev/snd/*
--------
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0                             
# owner: root                                         
# group: audio                                        
user::rw-                                             
user:sergeil:rw-                                      
group::rw-                                            
mask::rw-                                             
other::---                                            

# file: dev/snd/midiC0D0
# owner: root           
# group: audio          
user::rw-               
user:sergeil:rw-        
group::rw-              
mask::rw-               
other::---              

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D1p
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---
---------------

But, as soon, as X server is started, user lose permissions to use alsa devices.

[sergeil@rawhide ~]$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0                             
# owner: root                                         
# group: audio                                        
user::rw-                                             
group::rw-                                            
mask::rw-                                             
other::---                                            

# file: dev/snd/midiC0D0
# owner: root           
# group: audio          
user::rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D1p
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
group::rw-
mask::rw-
other::---

So, X server restore standard ACL for alsa, but do not setup it again for user.


After X server is finished (not killed), user have access to alsa again

[sergeil@rawhide ~]$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0                             
# owner: root                                         
# group: audio                                        
user::rw-                                             
user:sergeil:rw-                                      
group::rw-                                            
mask::rw-                                             
other::---                                            

# file: dev/snd/midiC0D0
# owner: root           
# group: audio          
user::rw-               
user:sergeil:rw-        
group::rw-              
mask::rw-               
other::---              

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D1p
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:sergeil:rw-
group::rw-
mask::rw-
other::---

Comment 3 Sergei LITVINENKO 2009-03-21 14:10:11 UTC
Problem can be solved by restoring fragment (assign CK_XINIT_SESSION) from F10.
PS: Variable XDG_SESSION_COOKIE is already defined here.


[sergeil@rawhide ~]$ diff -urN /etc/X11/xinit/xinitrc-common.org /etc/X11/xinit/xinitrc-common
--- /etc/X11/xinit/xinitrc-common.org   2009-03-21 15:51:42.000000000 +0200
+++ /etc/X11/xinit/xinitrc-common       2009-03-21 15:58:26.000000000 +0200
@@ -64,7 +64,10 @@
   fi
 fi

+#CK_XINIT_SESSION=
+#if [ -x /usr/bin/ck-xinit-session -a -z "$XDG_SESSION_COOKIE" ]; then
+#    CK_XINIT_SESSION="/usr/bin/ck-xinit-session"
+#fi
+
 CK_XINIT_SESSION=
-if [ -x /usr/bin/ck-xinit-session -a -z "$XDG_SESSION_COOKIE" ]; then
-    CK_XINIT_SESSION="/usr/bin/ck-xinit-session"
-fi
+[ -x /usr/bin/ck-xinit-session ] && CK_XINIT_SESSION="/usr/bin/ck-xinit-session"

Comment 4 Sergei LITVINENKO 2009-03-21 15:56:31 UTC
Variable XDG_SESSION_COOKIE is known in text console (after user logon).

So, if user start X system from console (by running startx), CK_XINIT_SESSION will be unknown and user lose access, as minimum, to sound.


PS: IMHO, startx have to undefine variable XDG_SESSION_COOKIE or make some other preparation.

Comment 5 Sergei LITVINENKO 2009-03-23 19:04:03 UTC
Resolving of problem is simple:
to add "unset XDG_SESSION_COOKIE" in /usr/bin/startx after "unset SESSION_MANAGER"


[root@rawhide ~]# more /usr/bin/startx
...
unset DBUS_SESSION_BUS_ADDRESS
unset SESSION_MANAGER
unset XDG_SESSION_COOKIE
...

Comment 6 Adam Jackson 2009-05-08 17:50:11 UTC
Fixed in xinit 1.0.9-7.fc11, thanks!