With well defined and kernel-supplied node names, we no longer need
to support a possible stack of conflicting symlinks and node names.
Only symlinks with identical names can be claimed by multiple devices.
This shrinks the former /dev/.udev/names/ significantly.
Also the /dev/{block,char}/MAJ:MIN" links are excluded from the name
stack - they are unique and can not conflict.
Starting from version 1.4, cups now uses libusb and printer USB devices instead
of the usblp generated /dev/usb/lpX ones. In order to not require the cups USB
backend to run as root now, change raw USB printer devices to be root:lp 0660,
similar to usblpX devices.
This might also enable the hplip backend to not run as root, since this has
always used raw device nodes.
https://launchpad.net/bugs/420015
Fix spelling in docbook comments, code comments, and a local variable
name. Thanks to "ispell -h" for docbook HTML and "scspell" for source
code.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
The newer firewire-core driver exposes per-device character device files,
called /dev/fw[0-9]*, in contrast to the older raw1394, video1394, dv1394
drivers which created one global file or per-controller files.
This allows to set ownership, permissions, or/ and access control lists
for each device file based on device type markers obtained from sysfs.
The "units" attribute which is used for this purpose has become available
in Linux 2.6.31(-rc1) by commit 0210b66dd88a2a1e451901b00378a2068b6ccb35.
The added rules match identifiers of
- IIDC devices:
industrial cameras and some webcams,
- AV/C devices:
camcorders, set-top boxes, TV sets, audio devices, and similar
devices.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On Fri, May 22, 2009 at 16:15, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote:
> I've been looking at what is responsible for all the path lookup activity in
> coldplug. On my debian stable system, it looks like every device gets its
> parent looked up in sysfs. I think this is due to SUBSYSTEMS matches.
>
> I see the udev default rules are different, but it looks like they still
> test for SUBSYSTEMS on every single device. Should we add SUBSYSTEM="scsi_generic"
> to these three rules?
UDev follows the kernel given name, and re-uses the kernel created
device node. If the kernel and spcecified udev rules disagree, the
udev specified node node is created and the kernel-created on is
deleted.
I don't see any security implications, to be actually useful,
/dev/cpu/<n>/cpuid should be world readable. The cpuid instruction
can be called from userspace anyway, so there is nothing to hide.
The device does not support any write operation, so 0444 should
suffice.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
On Fri, Dec 26, 2008 at 01:26, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Dec 26, 2008 at 12:39:16AM +0100, Kay Sievers wrote:
>> On Fri, Dec 26, 2008 at 00:26, Karel Zak <kzak@redhat.com> wrote:
>> > The upstream raw(8) command supports /dev/rawctl and also
>> > /dev/raw/rawctl. I think it makes more sense to use raw/rawctl when
>> > you have all your raw devices in raw/ subdirectory (e.g. /dev/raw/raw<N>).
>>
>> The raw tool looks for /dev/rawctl first and the fallback to
>> /dev/raw/rawctl is named DEVFS_*. Should we turn that order around and
>> remove the devfs notion from the raw tool and let udev create a
>> dev/raw/rawctl node?
>
> Yeah. Fixed, committed and pushed.
>
> $ strace -e open ./raw
> open("/dev/raw/rawctl", O_RDWR) = -1 ENOENT (No such file or directory)
> open("/dev/rawctl", O_RDWR) = -1 ENOENT (No such file or directory)
>
> I have also removed the #ifdef OLD_RAW_DEVS (/dev/raw<N>) junk.
A note on /dev/raw1394's security implications:
1. You cannot access local memory through raw1394, except
for ROMs and CSRs that are exposed to other nodes any way.
2. It is extremely hard to manipulate data on attached
SBP-2 devices (FireWire storage devices).
3. You can disturb operation of the FireWire bus, e.g.
creating a DoS situation for audio/video applications, for
SBP-2 devices, or eth1394 network interfaces.
4. If another PC is attached to the FireWire bus, it may be
possible to read or overwrite the entire RAM of that remote PC.
This depends on the PC's configuration. Most FireWire controllers
support this feature (yes, it's not a bug, or at least wasn't
intended to be one...) but not all OSs enable the feature.
Actually, a cheap setup to achieve #1 by #4 is to have two
FireWire controllers in the PC and connect them.
https://bugs.launchpad.net/ubuntu/+source/kino/+bug/6290/comments/21
specialix_rioctl: no kernel name symlink
specialix_sxctl: no kernel name symlink
bus/usb: 0644 -> 0664
ppdev: lp
dri: 0666 -> 0660
js: no kernel name symlink
On Thu, Oct 30, 2008 at 03:55, Tejun Heo <tj@kernel.org> wrote:
The appropriate default timeout differs depending on the transport and
the type of the attached device, so the above two rules harm more than
help. The affect of the above two rules weren't visible for some
reason but with recent block layer timeout update, they actually work
and cause problems.
None of these rules is supposed to be changed by users, so move
them out of /etc. Custom rules, and automatically generated rules
stay in /etc. All rules are still processed in lexical order,
regardless which directory they live in.
2008-07-18 15:56:03 +02:00
Renamed from etc/udev/rules.d/50-udev-default.rules (Browse further)
