Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 140853 - need sane way to manage permissions for devices, 3rd-party RPMS, defaults, etc
Summary: need sane way to manage permissions for devices, 3rd-party RPMS, defaults, etc
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Depends On:
Blocks: FC7Target
TreeView+ depends on / blocked
Reported: 2004-11-25 16:38 UTC by Christian Schaller
Modified: 2013-03-06 03:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-03 02:52:09 UTC

Attachments (Terms of Use)

Description Christian Schaller 2004-11-25 16:38:46 UTC
We are developing a Streaming Server, 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.

Comment 1 Harald Hoyer 2004-11-26 09:26:24 UTC
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?

Comment 2 Christian Schaller 2004-11-26 12:41:29 UTC
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)

Comment 3 Harald Hoyer 2004-11-26 13:11:11 UTC
oh, you will also have to look in /etc/security/console.perms what
pam_console changes on login/logout.

Comment 4 Christian Schaller 2004-11-26 14:50:05 UTC
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?

Comment 5 Harald Hoyer 2004-11-26 15:12:42 UTC
yep, ok, a "media" group could not hurt.. reassigning to setup

Comment 6 Bill Nottingham 2004-11-28 20:41:25 UTC
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.

Comment 7 Christian Schaller 2004-11-28 22:40:57 UTC
Ok, I start lobbying for bundling Flumotion on fedora-devel then.

Comment 8 Colin Walters 2004-12-14 18:42:16 UTC
A better solution than chowning devices and using groups is to
add/remove ACLs.

Comment 9 Christian Schaller 2004-12-14 19:34:59 UTC
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

Comment 10 Colin Walters 2004-12-14 21:05:35 UTC
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.

Comment 11 Christian Schaller 2004-12-15 10:15:09 UTC
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')

Comment 12 Colin Walters 2004-12-15 14:23:28 UTC
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.

Comment 13 Colin Walters 2004-12-16 16:15:33 UTC
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.

Comment 14 Christian Schaller 2005-05-05 16:07:24 UTC
updating this to fc4 as it is still just as valid there.

Comment 15 Christian Schaller 2006-04-25 14:36:49 UTC
Pinging this again as it is just as valid in FC5 in the hope that it will be
resolved for FC6.

Comment 16 John (J5) Palmieri 2006-04-25 14:53:40 UTC
Upstream is working on a solution called PolicyKit.  It should be the shizzle :-)

Comment 17 Red Hat Bugzilla 2007-02-05 18:55:10 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 18 David Zeuthen 2007-02-07 03:11:37 UTC
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).

Comment 19 Ludwig Nussel 2007-02-16 09:49:15 UTC
On SUSE Linux resmgr resp. a helper program manages ACLs on device files since 
some releases:

Here one would run e.g.
# echo allow sound user=flumotion > /etc/resmgr.conf.d/50-flumotion.conf

Comment 20 David Zeuthen 2007-02-20 05:10:05 UTC
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.

Comment 21 David Zeuthen 2007-02-20 05:13:07 UTC
(fixing up Summary)

Comment 22 Christian Schaller 2007-02-20 09:29:47 UTC
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)

Comment 23 David Zeuthen 2007-02-25 19:29:23 UTC
(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...

Comment 24 David Zeuthen 2007-04-03 02:52:09 UTC
OK, I've written some docs about this and committed it upstream. It will hit the
hal-docs package on the next package update;a=commitdiff;h=df05ad6981dbd2158386c1e9a0190a973f7f4f45

So I'm closing this bug as Rawhide as the requested functionality is already
available. Thanks!

Note You need to log in before you can comment on or make changes to this bug.