Changeset 81a73ed8 for postlfs/config/devices.xml
- Timestamp:
- 03/25/2020 03:07:11 PM (4 years ago)
- Branches:
- 10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal
- Children:
- 986f53b9
- Parents:
- fa3edfef
- File:
-
- 1 edited
-
postlfs/config/devices.xml (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
-
postlfs/config/devices.xml
rfa3edfef r81a73ed8 20 20 </indexterm> 21 21 22 <para>Although most devices needed by packages in BLFS and beyond are set up 23 properly by <application>udev</application> using the default rules installed 24 by LFS in <filename class="directory">/etc/udev/rules.d</filename>, there are 25 cases where the rules must be modified or augmented.</para> 22 <para> 23 Although most devices needed by packages in BLFS and beyond are set up 24 properly by <application>udev</application> using the default rules 25 installed by LFS in <filename 26 class="directory">/etc/udev/rules.d</filename>, there are cases where 27 the rules must be modified or augmented. 28 </para> 26 29 27 30 <para condition="html" role="usernotes">User Notes: … … 31 34 <title>Multiple Sound Cards</title> 32 35 33 <para>If there are multiple sound cards in a system, the "default" 34 sound card becomes random. The method to establish sound card order 35 depends on whether the drivers are modules or not. If the sound card 36 drivers are compiled into the kernel, control is via kernel command line 37 parameters in <filename>/boot/grub/grub.cfg</filename>. For example, 38 if a system has both an FM801 card and a SoundBlaster PCI card, the 39 following can be appended to the command line:</para> 36 <para> 37 If there are multiple sound cards in a system, the "default" 38 sound card becomes random. The method to establish sound card order 39 depends on whether the drivers are modules or not. If the sound card 40 drivers are compiled into the kernel, control is via kernel command line 41 parameters in <filename>/boot/grub/grub.cfg</filename>. For example, 42 if a system has both an FM801 card and a SoundBlaster PCI card, the 43 following can be appended to the command line: 44 </para> 40 45 41 46 <screen><literal>snd-fm801.index=0 snd-ens1371.index=1</literal></screen> 42 47 43 <para>If the sound card drivers are built as modules, the order can be 44 established in the <filename>/etc/modprobe.conf</filename> file 45 with:</para> 48 <para> 49 If the sound card drivers are built as modules, the order can be 50 established in the <filename>/etc/modprobe.conf</filename> file with: 51 </para> 46 52 47 53 <screen><literal>options snd-fm801 index=0 … … 53 59 <title>USB Device Issues</title> 54 60 55 <para>USB devices usually have two kinds of device nodes associated with 56 them.</para> 57 58 <para>The first kind is created by device-specific drivers (e.g., 59 usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass storage 60 device would be /dev/sdb, and a USB printer would be /dev/usb/lp0. These 61 device nodes exist only when the device-specific driver is loaded.</para> 62 63 <para>The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is 64 the bus number and DDD is the device number) are created even if the device 65 doesn't have a kernel driver. By using these "raw" USB device nodes, an 66 application can exchange arbitrary USB packets with the device, i.e., 67 bypass the possibly-existing kernel driver.</para> 68 69 <para>Access to raw USB device nodes is needed when a userspace program is 70 acting as a device driver. However, for the program to open the device 71 successfully, the permissions have to be set correctly. By default, due to 72 security concerns, all raw USB devices are owned by user root and group 73 usb, and have 0664 permissions (the read access is needed, e.g., for lsusb 74 to work and for programs to access USB hubs). Packages (such as SANE and 75 libgphoto2) containing userspace USB device drivers also ship udev rules 76 that change the permissions of the controlled raw USB devices. That is, rules 77 installed by SANE change permissions for known scanners, but not printers. 78 If a package maintainer forgot to write a rule for your device, 79 report a bug to both BLFS (if the package is there) and upstream, and 80 you will need to write your own rule.</para> 81 82 <para>There is one situation when such fine-grained access control with 83 pre-generated udev rules doesn't work. Namely, PC emulators such as KVM, 84 QEMU and VirtualBox use raw USB device nodes to present arbitrary USB 85 devices to the guest operating system (note: patches are needed in order to 86 get this to work without the obsolete /proc/bus/usb mount point described 87 below). Obviously, maintainers of these packages cannot know which USB 88 devices are going to be connected to the guest operating system. You can 89 either write separate udev rules for all needed USB devices yourself, or 90 use the default catch-all "usb" group, members of which can send 91 arbitrary commands to all USB devices. </para> 92 93 <para>Before Linux-2.6.15, raw USB device access was performed not with 94 /dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD 95 pseudofiles. Some applications (e.g., VMware Workstation) still use only 96 this deprecated technique and can't use the new device nodes. For them to 97 work, use the "usb" group, but remember that members will have unrestricted 98 access to all USB devices. To create the fstab entry for the obsolete 99 usbfs filesystem:</para> 61 <para> 62 USB devices usually have two kinds of device nodes associated with them. 63 </para> 64 65 <para> 66 The first kind is created by device-specific drivers (e.g., 67 usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass 68 storage device would be /dev/sdb, and a USB printer would be 69 /dev/usb/lp0. These device nodes exist only when the device-specific 70 driver is loaded. 71 </para> 72 73 <para> 74 The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is 75 the bus number and DDD is the device number) are created even if the 76 device doesn't have a kernel driver. By using these "raw" USB device 77 nodes, an application can exchange arbitrary USB packets with the 78 device, i.e., bypass the possibly-existing kernel driver. 79 </para> 80 81 <para> 82 Access to raw USB device nodes is needed when a userspace program is 83 acting as a device driver. However, for the program to open the device 84 successfully, the permissions have to be set correctly. By default, due 85 to security concerns, all raw USB devices are owned by user root and 86 group usb, and have 0664 permissions (the read access is needed, e.g., 87 for lsusb to work and for programs to access USB hubs). Packages (such 88 as SANE and libgphoto2) containing userspace USB device drivers also 89 ship udev rules that change the permissions of the controlled raw USB 90 devices. That is, rules installed by SANE change permissions for known 91 scanners, but not printers. If a package maintainer forgot to write 92 a rule for your device, report a bug to both BLFS (if the package is 93 there) and upstream, and you will need to write your own rule. 94 </para> 95 96 <para> 97 There is one situation when such fine-grained access control with 98 pre-generated udev rules doesn't work. Namely, PC emulators such as KVM, 99 QEMU and VirtualBox use raw USB device nodes to present arbitrary USB 100 devices to the guest operating system (note: patches are needed in order 101 to get this to work without the obsolete /proc/bus/usb mount point 102 described below). Obviously, maintainers of these packages cannot know 103 which USB devices are going to be connected to the guest operating 104 system. You can either write separate udev rules for all needed USB 105 devices yourself, or use the default catch-all "usb" group, members 106 of which can send arbitrary commands to all USB devices. 107 </para> 108 109 <para> 110 Before Linux-2.6.15, raw USB device access was performed not with 111 /dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD 112 pseudofiles. Some applications (e.g., VMware Workstation) still use only 113 this deprecated technique and can't use the new device nodes. For them to 114 work, use the "usb" group, but remember that members will have 115 unrestricted access to all USB devices. To create the fstab entry for 116 the obsolete usbfs filesystem: 117 </para> 100 118 101 119 <screen><literal>usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0</literal></screen> 102 120 103 <note><para>Adding users to the "usb" group is inherently insecure, as they 104 can bypass access restrictions imposed through the driver-specific USB 105 device nodes. For instance, they can read sensitive data from USB hard drives 106 without being in the "disk" group. Avoid adding users to this group, if 107 you can.</para></note> 121 <note> 122 <para> 123 Adding users to the "usb" group is inherently insecure, as they can 124 bypass access restrictions imposed through the driver-specific USB 125 device nodes. For instance, they can read sensitive data from USB 126 hard drives without being in the "disk" group. Avoid adding users 127 to this group, if you can. 128 </para> 129 </note> 108 130 109 131 </sect2> … … 112 134 <title>Udev Device Attributes</title> 113 135 114 <para>Fine-tuning of device attributes such as group name and permissions 115 is possible by creating extra <application>udev</application> rules, 116 matching on something like this. The vendor and product can be found by 117 searching the <filename class='directory'>/sys/devices</filename> directory 118 entries or using <command>udevadm info</command> after the device has been 119 attached. See the documentation in the current 120 <application>udev</application> directory of 121 <filename class='directory'>/usr/share/doc</filename> for details.</para> 136 <para> 137 Fine-tuning of device attributes such as group name and permissions 138 is possible by creating extra <application>udev</application> rules, 139 matching on something like this. The vendor and product can be found by 140 searching the <filename class='directory'>/sys/devices</filename> 141 directory entries or using <command>udevadm info</command> after the 142 device has been attached. See the documentation in the current 143 <application>udev</application> directory of <filename 144 class='directory'>/usr/share/doc</filename> for details. 145 </para> 122 146 123 147 <screen><literal>SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \ 124 148 GROUP:="scanner", MODE:="0660"</literal></screen> 125 149 126 <note><para>The above line is used for descriptive purposes only. The 127 scanner <application>udev</application> rules are put into place when 128 installing <xref linkend='sane'/>.</para></note> 150 <note> 151 <para> 152 The above line is used for descriptive purposes only. The 153 scanner <application>udev</application> rules are put into place when 154 installing <xref linkend='sane'/>. 155 </para> 156 </note> 129 157 130 158 </sect2> … … 141 169 <title>Devices for Servers</title> 142 170 143 <para>In some cases, it makes sense to disable 144 <application>udev</application> completely and create static devices. 145 Servers are one example of this situation. Does a server need the 146 capability of handling dynamic devices? Only the system administrator can 147 answer that question, but in many cases the answer will be no.</para> 148 149 <para>If dynamic devices are not desired, then static devices must be 150 created on the system. In the default configuration, the 151 <filename>/etc/rc.d/rcS.d/S10udev</filename> boot script mounts a 152 <systemitem class="filesystem">tmpfs</systemitem> partition over the 153 <filename class="directory">/dev</filename> directory. This problem can be 154 overcome by mounting the root partition temporarily:</para> 155 156 <warning><para>If the instructions below are not followed carefully, your 157 system could become unbootable.</para></warning> 171 <para> 172 In some cases, it makes sense to disable 173 <application>udev</application> completely and create static devices. 174 Servers are one example of this situation. Does a server need the 175 capability of handling dynamic devices? Only the system administrator 176 can answer that question, but in many cases the answer will be no. 177 </para> 178 179 <para> 180 If dynamic devices are not desired, then static devices must be 181 created on the system. In the default configuration, the 182 <filename>/etc/rc.d/rcS.d/S10udev</filename> boot script mounts a 183 <systemitem class="filesystem">tmpfs</systemitem> partition over the 184 <filename class="directory">/dev</filename> directory. This problem can 185 be overcome by mounting the root partition temporarily: 186 </para> 187 188 <warning> 189 <para> 190 If the instructions below are not followed carefully, your 191 system could become unbootable. 192 </para> 193 </warning> 158 194 159 195 … … 163 199 umount /mnt</userinput></screen> 164 200 165 <para>At this point, the system will use static devices upon the next 166 reboot. Create any desired additional devices using 167 <command>mknod</command>.</para> 168 169 <para>If you want to restore the dynamic devices, recreate the 170 <filename>/etc/rc.d/rcS.d/{S10udev,S50udev_retry}</filename> symbolic 171 links and reboot again. Static devices do not need to be removed (console 172 and null are always needed) because they are covered by the <systemitem 173 class="filesystem">tmpfs</systemitem> partition. Disk usage for devices is 174 negligible (about 20–30 bytes per entry.)</para> 201 <para> 202 At this point, the system will use static devices upon the next 203 reboot. Create any desired additional devices using 204 <command>mknod</command>. 205 </para> 206 207 <para> 208 If you want to restore the dynamic devices, recreate the 209 <filename>/etc/rc.d/rcS.d/{S10udev,S50udev_retry}</filename> symbolic 210 links and reboot again. Static devices do not need to be removed 211 (console and null are always needed) because they are covered by the 212 <systemitem class="filesystem">tmpfs</systemitem> partition. Disk 213 usage for devices is negligible (about 20–30 bytes per entry.) 214 </para> 175 215 176 216 </sect2> … … 179 219 <title>Devices for DVD Drives</title> 180 220 181 <para>If the initial boot process does not set up the 182 <systemitem>/dev/dvd</systemitem> device properly, it can 183 be installed using the following modification to the default udev rules. 184 As the <systemitem class="username">root</systemitem> user, run:</para> 221 <para> 222 If the initial boot process does not set up the 223 <systemitem>/dev/dvd</systemitem> device properly, it can 224 be installed using the following modification to the default udev rules. 225 As the <systemitem class="username">root</systemitem> user, run: 226 </para> 185 227 186 228 <screen><userinput>sed '1d;/SYMLINK.*cdrom/ a\
Note:
See TracChangeset
for help on using the changeset viewer.
