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
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:
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
Ok, I start lobbying for bundling Flumotion on fedora-devel then.
A better solution than chowning devices and using groups is to
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:
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
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
Here flumotion would just need to drop an appropriate XML file somewhere in
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!
> 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
So I'm closing this bug as Rawhide as the requested functionality is already