Bug 140853

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!