Tomas Mraz wrote:
On Thu, 2007-08-30 at 11:44 +0000, Boyan wrote:
Hi,
Recently after upgrade in rawhide (2-3 days ago) I'm not able to use correctly any program using sound. The reason is that the ownership and mode for /dev files are not like before. I think before they was like this:
crw------- 1 MY_USER root
Now they are:
crw-rw---- 1 root root
Excluding /dev/dsp which now is: crw-rw-rw- 1 root root
but everything now uses alsa and the files in /dev/snd/* can not be opened by users.
Anybody know what changed and how to reconfigure it back?
HAL daemon must be running.
The access is now granted by HAL daemon setting ACLs on the device nodes. 'getfacl /dev/snd/controlC0' should show whether they are properly assigned.
Ok, it seems now that ACL's are required for working sound. It's a bit strange for me. My kernel is not fedora's kernel, and I think I'm not the only one who don't use ACL's and hald.
root@b:~# /etc/init.d/haldaemon restart Stopping HAL daemon: [FAILED] and after 1-2min: Starting HAL daemon: [FAILED]
root@b:~# setfacl -m u:b:rw /dev/snd/* setfacl: /dev/snd/controlC0: Operation not supported setfacl: /dev/snd/pcmC0D0c: Operation not supported setfacl: /dev/snd/pcmC0D0p: Operation not supported setfacl: /dev/snd/pcmC0D1c: Operation not supported setfacl: /dev/snd/pcmC0D2c: Operation not supported setfacl: /dev/snd/pcmC0D3c: Operation not supported setfacl: /dev/snd/pcmC0D4p: Operation not supported setfacl: /dev/snd/seq: Operation not supported setfacl: /dev/snd/timer: Operation not supported
Anything more conventional excluding doing chown every time? I'm the only one using this computer. I'm wondering what was the problem with the old and working way...
On Thu, 2007-08-30 at 15:30 +0300, Boyan wrote:
Tomas Mraz wrote:
On Thu, 2007-08-30 at 11:44 +0000, Boyan wrote:
Hi,
Recently after upgrade in rawhide (2-3 days ago) I'm not able to use correctly any program using sound. The reason is that the ownership and mode for /dev files are not like before. I think before they was like this:
crw------- 1 MY_USER root
Now they are:
crw-rw---- 1 root root
Excluding /dev/dsp which now is: crw-rw-rw- 1 root root
but everything now uses alsa and the files in /dev/snd/* can not be opened by users.
Anybody know what changed and how to reconfigure it back?
HAL daemon must be running.
The access is now granted by HAL daemon setting ACLs on the device nodes. 'getfacl /dev/snd/controlC0' should show whether they are properly assigned.
Ok, it seems now that ACL's are required for working sound. It's a bit strange for me. My kernel is not fedora's kernel, and I think I'm not the only one who don't use ACL's and hald.
root@b:~# /etc/init.d/haldaemon restart Stopping HAL daemon: [FAILED] and after 1-2min: Starting HAL daemon: [FAILED]
root@b:~# setfacl -m u:b:rw /dev/snd/* setfacl: /dev/snd/controlC0: Operation not supported setfacl: /dev/snd/pcmC0D0c: Operation not supported setfacl: /dev/snd/pcmC0D0p: Operation not supported setfacl: /dev/snd/pcmC0D1c: Operation not supported setfacl: /dev/snd/pcmC0D2c: Operation not supported setfacl: /dev/snd/pcmC0D3c: Operation not supported setfacl: /dev/snd/pcmC0D4p: Operation not supported setfacl: /dev/snd/seq: Operation not supported setfacl: /dev/snd/timer: Operation not supported
Anything more conventional excluding doing chown every time? I'm the only one using this computer. I'm wondering what was the problem with the old and working way...
You can keep /etc/security/console.perms.d/50-default.perms from older pam package releases. pam_console module is still in pam configs so it will work. I don't think that the module will be removed from the configs for F8 but for F9 it probably will so you should change your kernel to support ACLs on tmpfs anyway.
As for the reasons why we cannot keep the old working way: https://bugzilla.redhat.com/show_bug.cgi?id=259141#c3
On Thu, Aug 30, 2007 at 02:46:49PM +0200, Tomas Mraz wrote:
As for the reasons why we cannot keep the old working way: https://bugzilla.redhat.com/show_bug.cgi?id=259141#c3
That is truly bad news. I say that because hal has a long history of doing something without providing well documented means to change that behaviour in situations where provided defaults are inappropriate. Until such mechanisms exist no amount of shouting NOTABUG will help.
Michal
Tomas Mraz wrote:
On Thu, 2007-08-30 at 15:30 +0300, Boyan wrote:
Tomas Mraz wrote:
On Thu, 2007-08-30 at 11:44 +0000, Boyan wrote:
Hi,
Recently after upgrade in rawhide (2-3 days ago) I'm not able to use correctly any program using sound. The reason is that the ownership and mode for /dev files are not like before. I think before they was like this:
crw------- 1 MY_USER root
Now they are:
crw-rw---- 1 root root
Excluding /dev/dsp which now is: crw-rw-rw- 1 root root
but everything now uses alsa and the files in /dev/snd/* can not be opened by users.
Anybody know what changed and how to reconfigure it back?
HAL daemon must be running.
The access is now granted by HAL daemon setting ACLs on the device nodes. 'getfacl /dev/snd/controlC0' should show whether they are properly assigned.
Ok, it seems now that ACL's are required for working sound. It's a bit strange for me. My kernel is not fedora's kernel, and I think I'm not the only one who don't use ACL's and hald.
root@b:~# /etc/init.d/haldaemon restart Stopping HAL daemon: [FAILED] and after 1-2min: Starting HAL daemon: [FAILED]
root@b:~# setfacl -m u:b:rw /dev/snd/* setfacl: /dev/snd/controlC0: Operation not supported setfacl: /dev/snd/pcmC0D0c: Operation not supported setfacl: /dev/snd/pcmC0D0p: Operation not supported setfacl: /dev/snd/pcmC0D1c: Operation not supported setfacl: /dev/snd/pcmC0D2c: Operation not supported setfacl: /dev/snd/pcmC0D3c: Operation not supported setfacl: /dev/snd/pcmC0D4p: Operation not supported setfacl: /dev/snd/seq: Operation not supported setfacl: /dev/snd/timer: Operation not supported
Anything more conventional excluding doing chown every time? I'm the only one using this computer. I'm wondering what was the problem with the old and working way...
You can keep /etc/security/console.perms.d/50-default.perms from older pam package releases. pam_console module is still in pam configs so it will work. I don't think that the module will be removed from the configs for F8 but for F9 it probably will so you should change your kernel to support ACLs on tmpfs anyway.
As for the reasons why we cannot keep the old working way: https://bugzilla.redhat.com/show_bug.cgi?id=259141#c3
OK, compiled the kernel with ACLs for tmpfs. As you said I started hald, which required dbus:
b@b:~$ /etc/init.d/messagebus status dbus-daemon (pid 2268) is running... b@b:~$ /etc/init.d/haldaemon status hald (pid 2414) is running...
but the thing is that the whole this is more complicated than just chown the devices because after every reboot the ACLs are again reset. The point is that /dev is recreated every time and there is no way the ACLs after reboot to survive. Perhaps this is the role of hald and dbus, but how to configure them? Maybe the program requesting access to those devices should be communicating with dbus and hald? What about the simple programs which does not do that? If someone knows where to look, that would be great.
On Wed, 2007-09-05 at 10:42 +0000, Boyan wrote:
Tomas Mraz wrote:
On Thu, 2007-08-30 at 15:30 +0300, Boyan wrote:
root@b:~# setfacl -m u:b:rw /dev/snd/* setfacl: /dev/snd/controlC0: Operation not supported setfacl: /dev/snd/pcmC0D0c: Operation not supported setfacl: /dev/snd/pcmC0D0p: Operation not supported setfacl: /dev/snd/pcmC0D1c: Operation not supported setfacl: /dev/snd/pcmC0D2c: Operation not supported setfacl: /dev/snd/pcmC0D3c: Operation not supported setfacl: /dev/snd/pcmC0D4p: Operation not supported setfacl: /dev/snd/seq: Operation not supported setfacl: /dev/snd/timer: Operation not supported
Anything more conventional excluding doing chown every time? I'm the only one using this computer. I'm wondering what was the problem with the old and working way...
You can keep /etc/security/console.perms.d/50-default.perms from older pam package releases. pam_console module is still in pam configs so it will work. I don't think that the module will be removed from the configs for F8 but for F9 it probably will so you should change your kernel to support ACLs on tmpfs anyway.
As for the reasons why we cannot keep the old working way: https://bugzilla.redhat.com/show_bug.cgi?id=259141#c3
OK, compiled the kernel with ACLs for tmpfs. As you said I started hald, which required dbus:
b@b:~$ /etc/init.d/messagebus status dbus-daemon (pid 2268) is running... b@b:~$ /etc/init.d/haldaemon status hald (pid 2414) is running...
but the thing is that the whole this is more complicated than just chown the devices because after every reboot the ACLs are again reset. The point is that /dev is recreated every time and there is no way the ACLs after reboot to survive. Perhaps this is the role of hald and dbus, but how to configure them? Maybe the program requesting access to those devices should be communicating with dbus and hald? What about the simple programs which does not do that? If someone knows where to look, that would be great.
The hald should add the ACLs on behalf of ConsoleKit. If you use gdm for login, it should call ConsoleKit through dbus. Also the text console login should contain 'session optional pam_ck_connector.so' in its PAM configuration (/etc/pam.d/login) so the ACLs are assigned on text console logins as well.