IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In certain cut-down situations such as an installer or inside the
initramfs, we simply don't have any kind of name service. While we
could use rules without OWNER or GROUP, it's better to have the same
rules as a full system and have udevd ignore those parts of the rules.
Adds a --resolve-names=never switch to udevd that has this effect.
Scott found that the node /dev/pktcdvd can not be replaced by
/dev/pktcdvd/control by changing the rules, and re-trigger the
event. We used to create the new names before we cleaned up the
old ones, which can not work if we need to create subdir with
the same name.
Since a while we change the database with a "test" run, but do not update
the node and symlinks. We need to "force" all the time, to keep things
in sync.
$env{ID_PATH} includes the "-nst" suffix anyway, so we shouldn't append
it a second time as part of the rule creating the device file symlink.
Signed-off-by: Lennart Poettering <lennart@poettering.net>
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
