We are developing a Streaming Server, www.flumotion.net. Which we want to package and have working easily for users of Fedora and eventually Red Hat. This server is aimed at doing live streaming from various live sources including soundcard, firewire and tv capture cards. We currently install our server through the RPM as a separate user called flumotion and have it set up with a proper init script etc. But we are unsure of how to handle access to the devices in a nice way. Currently we have to ask people to chmod stuff under /dev. Looking at the devices it seems to us that the devices are owned by the first user who logs into the system and with root as group, but only the active user has the right access the devices. Which makes sense from a desktop usage point of view as having 5 concurrent users logging in and all outputing sound to the soundcard is not a working solution. But for our server which needs to access all these devices to get data it creates a situation where we can't create the user experience we want. Demanding that people only run the server as an user they log in with is the wrong solution IMHO. Demanding that people chmod the devices on reboot or change of user is also not a nice solution IMHO. We are wondering if the correct solution is for Fedora to set up a new group, called media for instance, which also had the rights to access the hardware. Then applications like ours could have its user added to that group to get hardware access to soundcard and video devices. Ordinary users would not be be member of this group, so you still avoid the issue of multiple users trying to access the hardware.
You could modify /etc/udev/permissions.d/50-udev.permissions and put your changes in /etc/udev/permissions.d/10-flumotion.permissions, which will then overwrite the 50-udev.permissions. In the post section of your rpm you create the group "media". Would that work?
Yes, that should work I guess. But reading the 50-udev.permisions file I see that dsp is set to dsp*:root:root:0660 Which I assume means that the /dev/dsp device should by default be: crw-rw---- But by default it seems dsp have crw------- as its default permisions. So I am guessing that the system that gives the logged in user access to the device is overiding the setting from the udev.permisions file? Is this a bug, or do we also need to alter something else? (sorry for being such a newbie)
oh, you will also have to look in /etc/security/console.perms what pam_console changes on login/logout.
I will try to workout some kind of temporary solution, like a special RPM people can install together with the program rpm to update their setups. But shouldn't this be possible to do without overridding the standard OS permissions setup? Our software is probably not the only one needing this, so having a media group setup by Fedora by default which users/servers like ours could be added to for access to such devices would be a cleaner solution. The problem with we doing it ourselves (as I was strongly told during lunch today :) is that it doesn't solve the problem for other programs needing that kind of access (and if everyone used this solution you would have different systems 'fighthing' over which setup to use) and there where also some strong concerns about 'messing with a distributions security settings through an RPM'. I know that changing this for FC3 is probably not an option, but maybe it should be added for FC4?
yep, ok, a "media" group could not hurt.. reassigning to setup
New groups can't be added to setup sanely, sorry. (doesn't take effect on upgrade, and you can't use %post scripts.) Without a specific package in the OS using this, we probably won't add a group.
Ok, I start lobbying for bundling Flumotion on fedora-devel then.
A better solution than chowning devices and using groups is to add/remove ACLs.
You mean as a temporary solution or do you mean to say that you think ACL is the permanent solution to this problem? I have no ACL experience but I found this doc: http://www.suse.de/~agruen/acl/chapter/fs_acl-en.pdf Am I correct to understand that running some setfacl command in %post in the RPM will enable me to give the binary/user the permissions it needs/wants?
To be more precise, a nicer way to do it would be for udev configuration files to be able to specify ACLs to be added to device nodes. For example, flumotion could drop in a /etc/udev/permissions/80-flumotion.permissions that had: acl dsp flumotion:rw This would just add the flumotion user. No groups involved.
Sounds workable. Should this bug be re-opened and reassigned to the udev product then? Also if we get support for this in udev is there a chance to get an update for FC3 so we can create third party packages doing this also before FC4? Also will these ACL permissions continue to work even after console.perms/pam_console changes permissions on the devices? (If not then the solution isn't that much 'cleaner')
In my quick experimentation, ACLs are preserved even after a file is chowned, but not after a chmod. So you're right, I think that will be a problem for pam_console. Maybe the best solution there is to have pam_console do ACLs too; not sure how feasible that is.
We discussed this particular bug as part of the larger issue of managing device permissions, and the conclusion seemed to be that HAL should manage this. Thus, reassigning and retitling.
updating this to fc4 as it is still just as valid there.
Pinging this again as it is just as valid in FC5 in the hope that it will be resolved for FC6.
Upstream is working on a solution called PolicyKit. It should be the shizzle :-)
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
So I'm hoping to get this into Fedora 7; the proposal is here http://lists.freedesktop.org/archives/hal/2007-February/007176.html Here flumotion would just need to drop an appropriate XML file somewhere in /usr/share/hal/fdi/policy/20thirdparty/ and things should Just Work(tm).
On SUSE Linux resmgr resp. a helper program manages ACLs on device files since some releases: http://forgeftp.novell.com/resmgr/web/ Here one would run e.g. # echo allow sound user=flumotion > /etc/resmgr.conf.d/50-flumotion.conf
This is now in Rawhide (e.g. the flumotion package can drop a file somewhere to get ACL's added for certain classes of devices) but I need to write some good docs (probably a hal man page detailing who all this works) before I close this bug.
(fixing up Summary)
Great stuff David! Hopefully we can support this for the next release of Flumotion (as I assume installing that file on older systems which do not support this doesn't break anything)
(In reply to comment #22) > Great stuff David! Thanks! > Hopefully we can support this for the next release of > Flumotion (as I assume installing that file on older systems which do not > support this doesn't break anything) That's right wrt. older releases. See also bug 229912 comment 1 for how we plan to use this feature to grant access to sound devices to gdm for accessible login. I've still need to provide some good docs for this so I'm keeping this bug open for a bit longer...
OK, I've written some docs about this and committed it upstream. It will hit the hal-docs package on the next package update http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=df05ad6981dbd2158386c1e9a0190a973f7f4f45 So I'm closing this bug as Rawhide as the requested functionality is already available. Thanks!