Device Permission Problems specifically with sound, cd/dvd writer and usb storage device n Fedora Core 10

(Last Updated 16/10/2009, email ashley@csse.uwa.edu.au)

Background Information

This documentation will detail how to fix and rectify the permission problem of udev devices in Linux specifically Fedora Core 10. If you looking at this document that means you have one of these symtoms

1. Audio works fine as root but any other login apart from root there is no audio which is rather annoying in a real multi user Linux environment.

2. People can use the CD/DVD Writer to look at CDs but they can’t use it to write.

3. Removable storage devices ie USB Hard disk or USB flash disk are mounted automatically with 755 permssion. You don’t want people looking at your removable volumes via remote connections ie like ssh.

This document will detail how to rectify this problems specifically under Fedora Core 10 but it should be applicable to any other distros as under the bonnet they are all effectively the same, its just how they are packaged.

If you have symptoms one and two mentioned above, the short story is that the rules written for the udev devices are wrong. Well not explicitely wrong, it’s just always owned by root regardless who ever logs onto the console ie

For the Sound Card it would be this

/dev/snd/*

/dev/mixer*

/dev/dsp*

For the CD/DVD drive it would be

/dev/sr0

/dev/cdrom (Usually it is sym linked to /dev/sr0)

/dev/cdrw (Usually it is sym linked to /dev/sr0)

/dev/dvd (Usually it is sym linked to /dev/sr0)

/dev/dvdrw (Usually it is sym linked to /dev/sr0)

/dev/scd0 (Usually it is sym linked to /dev/sr0)

And all these devices would be owned by root, the respective service group who has read/write permission and others which would have usually no read/write permissions. Thus that’s why the devices work for root at the console and not for any other user who logs onto the console.

Now the permission of the devices are governed by rules written in /etc/security. In the case case of Fedora Core 10, it is

/etc/security/console.perms.d/50-default.perms

Here is my attached 50-default.perms, check the section of “Custom Fix Permission”.

# device classes -- these are shell-style globs

<pilot>=/dev/pilot

<scanner>=/dev/scanner* /dev/usb/scanner*

<rio500>=/dev/usb/rio500

<fb>=/dev/fb /dev/fb[0-9]* \

/dev/fb/*

<kbd>=/dev/kbd

<joystick>=/dev/js[0-9]*

<gpm>=/dev/gpmctl

<dri>=/dev/nvidia* /dev/3dfx* /dev/dri/card*

<mainboard>=/dev/apm_bios

<pmu>=/dev/pmu

<bluetooth>=/dev/rfcomm*

<irda>=/dev/ircomm*

<dvb>=/dev/dvb/adapter*/*

# permission definitions

<console> 0600 <pilot> 0660 root.uucp

<console> 0660 <scanner> 0660 root.lp

<console> 0600 <fb> 0600 root

<console> 0600 <kbd> 0600 root

<console> 0600 <joystick> 0600 root

<console> 0700 <gpm> 0700 root

<console> 0600 <mainboard> 0600 root

<console> 0600 <rio500> 0600 root

<console> 0600 <pmu> 0600 root

<console> 0600 <bluetooth> 0600 root

<console> 0600 <irda> 0600 root

<console> 0600 <dvb> 0600 root

<xconsole> 0600 /dev/console 0600 root.root

<console> 0600 <dri> 0600 root

# Custom Fix Permission

#Video udev

<video>=/dev/video*

#Audio udev

<audio>=/dev/snd/* /dev/mixer* /dev/dsp*

#cdrom,cdrw,dvd,dvdrw,sdc0 are just sym links to sr

<dvdcdwriter>=/dev/sr*

<console> 0660 <video> 0660 root.pulse (The video group is not pulse)

<console> 0660 <audio> 0660 root.pulse

<console> 0660 <dvdcdwriter> 0660 root.disk

Now if you insert those changes, log out of the console and login the console and check the permissions ie by going to /dev. It should be assigned correctly to whoever logs into the console.

Now if you have symptom three, ie mountable volumes including usb hard disk or flash drives with a umask of either group or world read and possible world write permission. I found it’s a bit more come complex than writing some dev security rules. First of all you should understand the basic mechanism how a modern Linux system do mounting of removable volumes.

Most Linux system uses the HAL daemon to discover hardware which may or may not interact with components such as D-Bus and the windows manager.

The simplest case would be there HAL has no interaction with D-Bus or the Windows manager. If this is the case, when you plug in a removable volumes it will follow the rules / configurations found in either /etc/hal/fdi or /usr/share/hal/fdi (Based on Fedora Core 10 System).

/usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi

In my case it’s the file mentioned above which is a xml configuration file describing devices. What you want to change is the umask of the mountable volumes. Most mountable volumes which are shared cross playform will be either normally vfat or ntfs.

Ie for Fat base removable filesystem it would be something like this

<append key="volume.mount.valid_options" type="strlist">shortname=</append>

<append key="volume.mount.valid_options" type="strlist">codepage=</append>

<append key="volume.mount.valid_options" type="strlist">iocharset=</append>

<append key="volume.mount.valid_options" type="strlist">umask=</append>

<append key="volume.mount.valid_options" type="strlist">dmask=</append>

<append key="volume.mount.valid_options" type="strlist">fmask=</append>

<append key="volume.mount.valid_options" type="strlist">flush</append>

</match>

Ie for Ntfs base removable filesystem it would be something like this

<append key="volume.mount.valid_options" type="strlist">umask=</append>

</match>

Just assigned an appropriate umask setting ie 0077, where the console user only has read/write/execute permission.

Now that will work assuming Hal daemon doesn’t interract ie with D-Bus which talks to the Windows Manager. I’ve found if I’m using the Windows Manager ie like Gnome in Fedora 10, it talks to D-bus which talks to the Hal Daemon.

And it seems like the preference set (even if its explicitly not set) overrides the rules written for Hal Daemon. By default if you don’t set the umask setting of removable volumes by file system type, it sets the user as having writable/readable/executable, group and world with readable/executable permission (worst case scenario is group and world having readable/writable/executable permission).

I’ve managed to tracked it down to xml files which have to be present in your .gconf area in your home area. Basically there is a configuration file for each type of file system ie

$HOME/.gconf/system/storage/default_options/ntfs/%gconf.xml

$HOME/.gconf/system/storage/default_options/vfat/%gconf.xml

The contents of $HOME/.gconf/system/storage/default_options/ntfs/%gconf.xml

<?xml version="1.0"?>

<gconf>

<stringvalue>umask=0077</stringvalue>

</li>

</entry>

</gconf>

The contents of $HOME/.gconf/system/storage/default_options/vfat/%gconf.xml

<?xml version="1.0"?>

<gconf>

<stringvalue>shortname=lower</stringvalue>

</li>

</li>

<stringvalue>umask=0077</stringvalue>

</li>

</entry>

</gconf>

The other method of generating the required xml configuration file is running gconf-editor (if you don’t have it “yum install gconf-editor” or download the rpm)

Then you navigate to /system/storage/default_options/{filesystem type}/mount_options

Edit or add the key umask=0077, I did this for both fat and ntfs filesystem.

I’m still trying to puzzle things out about the Mac OSX 10.5.xx and its annoying the hell out of me.