* Re: Restricting USB access
From: Greg KH @ 2010-10-07 20:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
On Thu, Oct 07, 2010 at 03:50:55PM -0400, Ryan Lawrie wrote:
>
> Good afternoon,
>
> Just wondering if I could get your assistance with something.
>
> I need to secure the USB ports on my LAN workstations so they are not
> writable by users (other than a certain group that I specify). Is this type
> of restriction possible using udev rules?
USB ports are "writeable" or "readable", it depends on the devices you
plug into them that you could then read or write to.
> I was using PolicyKit before but since we've changed OS (from openSUSE11.0
> to 64-bit openSUSE11.2) that no longer seems to function properly.
> Everybody has access to the USB ports now.
You might want to just restrict the users for the specific devices using
a udev rule, or policykit, if that's still around.
What types of devices are you trying to restrict?
thanks,
greg k-h
^ permalink raw reply
* [RFD] Device Renaming Mechanism
From: Nao Nishijima @ 2010-10-08 5:23 UTC (permalink / raw)
To: gregkh, James.Bottomley, rwheeler
Cc: linux-kernel, linux-hotplug-devel, linux-hotplug,
masami.hiramatsu.pt
Hi,
I'm trying to solve a device name(or device node) mismatch problem caused by
device configuration changes. Now I have an idea of device renaming to solve it,
and would like to request for comments from kernel developers.
Device Name Mismatch
==========
Device names(e.g. sda) are assigned by the order of driver loading and device
recognizing (usually from small bus number). This may cause a device name
mismatch between previous and current boot whenever the device configuration is
changed. Suppose there is an application opens disk via /dev/sdb. When device
configuration changing (hot-plug, device breakdown) or system configuration
changing(driver loading order, changing modprobe.conf) causes changing order
device names. This device names does not always point to same disks.
This mismatch causes unexpected disk access and redundancy miss setting (e.g.
Multipath, software-raid), if you use device file names to a configuration file.
Udev Solution
======
Typically we use to avoid this problem we uses persistent device names provided
by udev.
Udev makes persistent symbolic links(by-{id, uuid, path, label}) pointing to each
device based on device information. Applications access the device via these
symbolic links. Udev solves mismatch between device name and physical disk.
However the persistent name mismatches kernel's device name.
This mismatch causes following 4 issues.
Issue 1: /proc/partitions, /proc/diskstat gives you device names
We have to run "ls -l /dev/disk/by-*" or "udevadm" for finding corresponding
persistent symbolic links.
Issue 2: dmesg output device name instead of persistent symbolic links
Users might not know which disk is sdX, because they identify the disk by a
persistent symbolic link.
Issue 3: Some system commands don't accept symbolic link(e.g. df, iostat,...)
These commands just expect sdX device name or check input by /proc information.
This will also occur on several GNOME/KDE/etc GUI sysadmin tools. :(
Issue 4: Undecided symbolic link
Even if we would like to introduce device names/persistent symbolic links
mapping tool to solve it, we can not determine a symbolic link from a device,
because several symbolic links point a device file.
Therefore, I think the symbolic link is not enough to solve. We need a
better solution.
Proposal
====
I'd like to propose introducing device renaming interface to solve these issues.
I think renaming device name in the kernel is the simplest way to solve mismatch
dmesg and /proc information. This can be done while kernel booting up(like
ifcfg). Of course, udev still needs to assign new name for each device via that
interface.
This proposal just requests to add a simple interface to kernel as below. And we
can continue to use user program without any modification.
int rename_device(const char *newname, const char *oldname)
Any comments, or suggestions are very welcome!
Best Regards,
--
Nao NISHIJIMA
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
Email： nao.nishijima.xt@hitachi.com
^ permalink raw reply
* Re: Restricting USB access
From: Ryan Lawrie @ 2010-10-08 14:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
Hi Greg,
Mostly, we're concerned with portable USB drives. (We still want USB mice
and keyboards to function properly) With openSUSE11.0 we were able to
restrict all USB access (in the org.freedesktop.hal.storage.mount-removable
file) and then add a list of privileged usernames into the policykit.conf
file to override permissions for those people. This allowed our special
users to use USB sticks while everyone else was unable to.
I'm trying to figure out if PolicyKit is still working for openSUSE11.2
(all the files seems to be there so I assumed that meant it was
available .... but the system doesn't seem to care what I put into those
files)
Could you give me some simple instructions on how to write a udev rule to
do this (I've never worked with udev before) .... or direct me to a good
tutorial website perhaps. I will do some more web hunting on that.
(I guess I will have to take care of the CD burner also. I want that to be
readable by everyone but not writable. Would udev rules work for this
also?)
Thanks very much for your assistance.
Take care,
Ryan
From: Greg KH <greg@kroah.com>
To: Ryan Lawrie <ryan.lawrie@hc-sc.gc.ca>
Cc: linux-hotplug@vger.kernel.org
Date: 2010-10-07 04:51 PM
Subject: Re: Restricting USB access
On Thu, Oct 07, 2010 at 03:50:55PM -0400, Ryan Lawrie wrote:
>
> Good afternoon,
>
> Just wondering if I could get your assistance with something.
>
> I need to secure the USB ports on my LAN workstations so they are not
> writable by users (other than a certain group that I specify). Is this
type
> of restriction possible using udev rules?
USB ports are "writeable" or "readable", it depends on the devices you
plug into them that you could then read or write to.
> I was using PolicyKit before but since we've changed OS (from
openSUSE11.0
> to 64-bit openSUSE11.2) that no longer seems to function properly.
> Everybody has access to the USB ports now.
You might want to just restrict the users for the specific devices using
a udev rule, or policykit, if that's still around.
What types of devices are you trying to restrict?
thanks,
greg k-h
^ permalink raw reply
* Re: Restricting USB access
From: Greg KH @ 2010-10-08 14:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
On Fri, Oct 08, 2010 at 10:25:31AM -0400, Ryan Lawrie wrote:
> Hi Greg,
>
> Mostly, we're concerned with portable USB drives. (We still want USB mice
> and keyboards to function properly) With openSUSE11.0 we were able to
> restrict all USB access (in the org.freedesktop.hal.storage.mount-removable
> file) and then add a list of privileged usernames into the policykit.conf
> file to override permissions for those people. This allowed our special
> users to use USB sticks while everyone else was unable to.
>
> I'm trying to figure out if PolicyKit is still working for openSUSE11.2
> (all the files seems to be there so I assumed that meant it was
> available .... but the system doesn't seem to care what I put into those
> files)
You should ask the policykit people about this, it's not really a
hotplug issue at all here. I'm not sure what they have changed over the
past few years in this area in that program.
> Could you give me some simple instructions on how to write a udev rule to
> do this (I've never worked with udev before) .... or direct me to a good
> tutorial website perhaps. I will do some more web hunting on that.
> (I guess I will have to take care of the CD burner also. I want that to be
> readable by everyone but not writable. Would udev rules work for this
> also?)
Well, block devices get "wierd" in that HAL is probably doing the
mounting of the device when it is seen by the system automatically. So
you need to tell it to only mount it 'read-only'. And I think that
falls back to policykit to handle properly, so I don't think writing a
udev here will help you out at all, sorry.
good luck,
greg k-h
^ permalink raw reply
* Re: Restricting USB access
From: Kay Sievers @ 2010-10-08 14:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
On Fri, Oct 8, 2010 at 16:25, Ryan Lawrie <ryan.lawrie@hc-sc.gc.ca> wrote:
> Mostly, we're concerned with portable USB drives. (We still want USB mice
> and keyboards to function properly) With openSUSE11.0 we were able to
> restrict all USB access (in the org.freedesktop.hal.storage.mount-removable
> file) and then add a list of privileged usernames into the policykit.conf
> file to override permissions for those people. This allowed our special
> users to use USB sticks while everyone else was unable to.
>
> I'm trying to figure out if PolicyKit is still working for openSUSE11.2
> (all the files seems to be there so I assumed that meant it was
> available .... but the system doesn't seem to care what I put into those
> files)
>
> Could you give me some simple instructions on how to write a udev rule to
> do this (I've never worked with udev before) .... or direct me to a good
> tutorial website perhaps. I will do some more web hunting on that.
> (I guess I will have to take care of the CD burner also. I want that to be
> readable by everyone but not writable. Would udev rules work for this
> also?)
Udev can't manage any permissions at such level. And USB *ports* don't
have any user permissions. Raw USB devices have, but they are not
user-assigned. USB storage devices like USB sticks are never
permission managed at the block device level, but only at mount.
Seems, you look for auto-mount permissions for removable devices,
which have nothing really to do with USB, but with the auto-mouter <->
user-session hookup.
These permissions are never applied to device nodes (which udev could
do), but only handled when an untrusted user asks to mount a device
(udisks/HAL ask if the calling user should be granted access).
It depends on the desktop. Up-to-date desktops use udisks/polkit for
that, others still use the deprecated and no longer maintained
HAL/PolicyKit.
Kay
^ permalink raw reply
* Re: Restricting USB access
From: Kay Sievers @ 2010-10-08 15:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
On Fri, Oct 8, 2010 at 16:35, Greg KH <greg@kroah.com> wrote:
> On Fri, Oct 08, 2010 at 10:25:31AM -0400, Ryan Lawrie wrote:
>> Could you give me some simple instructions on how to write a udev rule to
>> do this (I've never worked with udev before) .... or direct me to a good
>> tutorial website perhaps. I will do some more web hunting on that.
>> (I guess I will have to take care of the CD burner also. I want that to be
>> readable by everyone but not writable. Would udev rules work for this
>> also?)
>
> Well, block devices get "wierd" in that HAL is probably doing the
> mounting of the device when it is seen by the system automatically. So
> you need to tell it to only mount it 'read-only'. And I think that
> falls back to policykit to handle properly, so I don't think writing a
> udev here will help you out at all, sorry.
Right, udev is not in the game here besides that it handles the device
events, and broadcasts them to system services. It does no permissions
at all for these devices.
User-sessions/logged-in users can request mounting of storage devices
from the system, on behalf of the user. Untrusted users can cause
privileged operations to happen that way. The guard here is polkit, it
say yes or no these requests.
The details of all this are explained here:
http://people.redhat.com/davidz/Plumbers-2009-Sievers-Zeuthen-Replugging-The-Modern-Desktop.pdf
Kay
^ permalink raw reply
* Re: [RFD] Device Renaming Mechanism
From: Greg KH @ 2010-10-08 20:48 UTC (permalink / raw)
To: Nao Nishijima
Cc: gregkh, James.Bottomley, rwheeler, linux-kernel, linux-hotplug,
masami.hiramatsu.pt
In-Reply-To: <4CAEAAD4.2080504@hitachi.com>
On Fri, Oct 08, 2010 at 02:23:32PM +0900, Nao Nishijima wrote:
> Hi,
>
> I'm trying to solve a device name(or device node) mismatch problem caused by
> device configuration changes. Now I have an idea of device renaming to solve it,
> and would like to request for comments from kernel developers.
Hi,
We spoke at LinuxCon Tokyo about this, so it's good to see you continue
here on the mailing lists.
> Device Name Mismatch
> ==========
>
> Device names(e.g. sda) are assigned by the order of driver loading and device
> recognizing (usually from small bus number). This may cause a device name
> mismatch between previous and current boot whenever the device configuration is
> changed.
This is as it always has been.
> This mismatch causes unexpected disk access and redundancy miss setting (e.g.
> Multipath, software-raid), if you use device file names to a configuration file.
That's why most people know to not use the kernel name for their fstab,
and why distros haven't for a very long time, used them when installing.
> Udev Solution
> ======>
> Typically we use to avoid this problem we uses persistent device names provided
> by udev.
Yes.
> Udev makes persistent symbolic links(by-{id, uuid, path, label}) pointing to each
> device based on device information. Applications access the device via these
> symbolic links. Udev solves mismatch between device name and physical disk.
> However the persistent name mismatches kernel's device name.
> This mismatch causes following 4 issues.
>
> Issue 1: /proc/partitions, /proc/diskstat gives you device names
> We have to run "ls -l /dev/disk/by-*" or "udevadm" for finding corresponding
> persistent symbolic links.
That's fine, don't use the /proc files :)
> Issue 2: dmesg output device name instead of persistent symbolic links
> Users might not know which disk is sdX, because they identify the disk by a
> persistent symbolic link.
Again, that's fine as well, don't use "raw" dmesg output and expect it
to map to what the user has mounted. There are a number of tools to
handle the mapping of this out there by companies (IBM, CA, etc.)
> Issue 3: Some system commands don't accept symbolic link(e.g. df, iostat,...)
> These commands just expect sdX device name or check input by /proc information.
> This will also occur on several GNOME/KDE/etc GUI sysadmin tools. :(
Then we should fix those programs, it is a simple one line change. Can
you please tell us which programs you have tested and found problems
with?
> Issue 4: Undecided symbolic link
> Even if we would like to introduce device names/persistent symbolic links
> mapping tool to solve it, we can not determine a symbolic link from a device,
> because several symbolic links point a device file.
Huh? You want to move from a kernel name to the one that the user used?
As you are the user, you should know which one you used :)
> Therefore, I think the symbolic link is not enough to solve. We need a
> better solution.
I strongly disagree.
> Proposal
> ====
> I'd like to propose introducing device renaming interface to solve these issues.
Ick, no, please, no.
> I think renaming device name in the kernel is the simplest way to solve mismatch
> dmesg and /proc information. This can be done while kernel booting up(like
> ifcfg). Of course, udev still needs to assign new name for each device via that
> interface.
>
> This proposal just requests to add a simple interface to kernel as below. And we
> can continue to use user program without any modification.
>
> int rename_device(const char *newname, const char *oldname)
I'll quote a message that Kay wrote to me last week when I told him
about this talk. It's why we don't want to rename kernel devices, and
why using symlinks are the way to go:
- All links or nodes can be stat()'d an then /sys/dev/block/M:m
points to the kernel. So easy!
- Libudev provides all device meta information, list of links,
events. No app/management tool can ever work properly in 2010
that does not react on hotplug or device update events. 1980
is over, we are all 100% hotplug aware, or we die!
- Kernel device renaming is very fragile and only done for
netdevs because they can't have symlinks. There are many
cross-refs for blockdevs like holders/ slaves/ sysfs dirs,
they all need to be renamed atomically and race-free, which is
almost impossible I would say.
- Biggest problem with renaming is that the device gets
advertised and is accessed immediately by userspace. Renaming
after advertising (sysfs, devtmpfs, uevent) is very difficult,
racy, almost impossible.
- The only option to have named block devs is to have change the
block layer to create intermediate devices in sysfs (which are
advertised but not accessible as blockdevs) and then let
userspace hook into it and request a real blockdev with a
specified name, and only _after_ this create the real
blockdev. This is, and must be, not a renaming, but a naming.
Kay said he had lots more reasons why this shouldn't be done, if you
want them as well :)
Also, note that the network people are really wanting symlinks these
days, and the fact that renaming the device can cause problems, so
please don't look to them as the "correct" solution at all.
Hope this helps,
greg k-h
^ permalink raw reply
* udev rules for devices that do not have serial
From: Matteo Sgalaberni @ 2010-10-11 14:40 UTC (permalink / raw)
To: linux-hotplug
Hi,
I'm searching a way to write a udev rule for a device that do not expose
any unique value.
I need to attach multiple mobile phones and give to them the same device
name as in every phone I have different numbers... So I need to be sure
that when I receive a call or SMS from /dev/myphone1 is connected the
myphone1 and not myphone2 until reboots or attach-reattach.
The real problem is that the devices that I'm using are not exposing any
unique value from the usbinfo like iSerial or other unique serial
numbers...
I'm tring to do this with some Alcatel Ot-800 but is the same with other
phones...
Any suggestion?
Thanks!
Matteo
^ permalink raw reply
* Re: udev rules for devices that do not have serial
From: Kay Sievers @ 2010-10-11 15:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101011144030.GA17881@sgala.com>
On Mon, Oct 11, 2010 at 16:40, Matteo Sgalaberni <sgala@sgala.com> wrote:
> I'm searching a way to write a udev rule for a device that do not expose
> any unique value.
>
> I need to attach multiple mobile phones and give to them the same device
> name as in every phone I have different numbers... So I need to be sure
> that when I receive a call or SMS from /dev/myphone1 is connected the
> myphone1 and not myphone2 until reboots or attach-reattach.
>
> The real problem is that the devices that I'm using are not exposing any
> unique value from the usbinfo like iSerial or other unique serial
> numbers...
>
> I'm tring to do this with some Alcatel Ot-800 but is the same with other
> phones...
>
> Any suggestion?
I guess at the AT command level you can distinguish the phones pretty
easily. Might be that the layer of using /dev is just not the right
one to solve your problem.
Usually devices with all-the-same properties are identified by the
physical connection path. But that allows no re-config, not even for a
single device, and therefore might be not the right thing to use to
solve some setups.
Serial ports have both types of persistent identifiers in udev.
/dev/serial/by-id/ + by-path/
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h¼4c751802147f1ff21bf52a57a2976754949453
Kay
^ permalink raw reply
* udev seems to not recognize some devices when plugging them
From: Pedro Aguilar @ 2010-10-13 9:34 UTC (permalink / raw)
To: linux-hotplug
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 2533 bytes --]
Hi,
I'm working on a set-top-box that needs a wireless network using an
usb wireless adapter such as the d-link dwl-122 that is supported
under Linux.
I have a kernel 2.6.23.17, libc 2.6 and udev 129. For several reasons
I cannot upgrade the kernel :(
My problem is that after compiling the kernel with all the necessary
wireless modules (like mac80211), compiling and insmoding the usb
wireless driver (rt73), copying its fw, and connecting the usb
adapter, I have the following behaviour:
There isn't any change in /sys/. I would expect a new dir in
/sys/class/net (something like /sys/class/net/wlan0).
# ls /sys/class/net/
eth0 lo
If I write a 00-test.rules, when I connect the usb adapter it matches
and calls the test.sh script.
ACTION="add", SUBSYSTEM="usb", ATTR{idVendor}="07d1",
ATTR{idProduct}="3c0f", RUN+="/usr/bin/test.sh"
so I think the kernel is sending the event to udev, but I don't see
any net iface.
iwconfig doesn't give any wireless interface:
# iwconfig
eth0 no wireless extensions.
lo no wireless extensions.
lsusb and cat /proc/bus/usb/devices give the right ouput:
# lsusb
Bus 001 Device 011: ID 07d1:3c0f D-Link System
...
# cat /proc/bus/usb/devices
T: Bus\x01 Lev\x02 Prnt\x02 Port\x02 Cnt\x01 Dev#= 11 SpdH0 MxCh= 0
D: Ver= 2.00 Cls\0(>ifc ) Sub\0 Prot\0 MxPSd #Cfgs= 1
P: Vendor\ad1 ProdID<0f Rev= 1.01
S: Manufacturer=Ralink
S: Product\x11g Adapter
S: SerialNumber=1.0
C:* #Ifs= 1 Cfg#= 1 Atr€ MxPwrE0mA
I:* If#= 0 Alt= 0 #EPs= 7 Clsÿ(vend.) Subÿ Protÿ Driver=(none)
E: Ad(I) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
E: Ad\x01(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
E: Ad\x02(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
E: Ad\x03(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
E: Ad\x04(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
E: Ad\x05(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
E: Ad\x06(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
Here's the output I get when I connect the usb wireless adapter with
the kernel's usb debugging active:
usb 1-1.3: new high speed USB device using stm-ehci and address 10
usb 1-1.3: Product: 11g Adapter
usb 1-1.3: Manufacturer: Ralink
usb 1-1.3: SerialNumber: 1.0
usb 1-1.3: configuration #1 chosen from 1 choice
Other devices like usb mass storage devices work smoothly as well as
usb mice and keyboards. This happens with the usb wireless adapter
that I have tested.
I'm not sure if the problem is because I have old versions of
udev/kernel/libc or if I'm missing something.
Any ideas/hints?
Thanks in advance!
Regards,
--
Pedro Aguilar
http://www.paguilar.org/blog
^ permalink raw reply
* Re: udev seems to not recognize some devices when plugging them
From: Kay Sievers @ 2010-10-13 12:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTimRDapMMB3+v2YNF6TrLn3B4+RnZYmBzUseGYuh@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 3082 bytes --]
On Wed, Oct 13, 2010 at 11:34, Pedro Aguilar
<pedro.aguilar.iniestra@gmail.com> wrote:
> I'm working on a set-top-box that needs a wireless network using an
> usb wireless adapter such as the d-link dwl-122 that is supported
> under Linux.
> I have a kernel 2.6.23.17, libc 2.6 and udev 129. For several reasons
> I cannot upgrade the kernel :(
>
> My problem is that after compiling the kernel with all the necessary
> wireless modules (like mac80211), compiling and insmoding the usb
> wireless driver (rt73), copying its fw, and connecting the usb
> adapter, I have the following behaviour:
>
> There isn't any change in /sys/. I would expect a new dir in
> /sys/class/net (something like /sys/class/net/wlan0).
> # ls /sys/class/net/
> eth0 Â lo
>
> If I write a 00-test.rules, when I connect the usb adapter it matches
> and calls the test.sh script.
> ACTION="add", SUBSYSTEM="usb", ATTR{idVendor}="07d1",
> ATTR{idProduct}="3c0f", RUN+="/usr/bin/test.sh"
> so I think the kernel is sending the event to udev, but I don't see
> any net iface.
>
> iwconfig doesn't give any wireless interface:
> # iwconfig
> eth0 Â Â Â no wireless extensions.
> lo     no wireless extensions.
>
> lsusb and cat /proc/bus/usb/devices give the right ouput:
> # lsusb
> Bus 001 Device 011: ID 07d1:3c0f D-Link System
> ...
>
> # cat /proc/bus/usb/devices
> T: Â Bus\x01 Lev\x02 Prnt\x02 Port\x02 Cnt\x01 Dev#= 11 SpdH0 MxCh= 0
> D: Â Ver= 2.00 Cls\0(>ifc ) Sub\0 Prot\0 MxPSd #Cfgs= Â 1
> P: Â Vendor\ad1 ProdID<0f Rev= 1.01
> S: Â Manufacturer=Ralink
> S: Â Product\x11g Adapter
> S: Â SerialNumber=1.0
> C:* #Ifs= 1 Cfg#= 1 Atr€ MxPwrE0mA
> I:* If#= 0 Alt= 0 #EPs= 7 Clsÿ(vend.) Subÿ Protÿ Driver=(none)
> E: Â Ad(I) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
> E: Â Ad\x01(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
> E: Â Ad\x02(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
> E: Â Ad\x03(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
> E: Â Ad\x04(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
> E: Â Ad\x05(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
> E: Â Ad\x06(O) Atr\x02(Bulk) MxPS= 512 Ivl=0ms
>
> Here's the output I get when I connect the usb wireless adapter with
> the kernel's usb debugging active:
>
> usb 1-1.3: new high speed USB device using stm-ehci and address 10
> usb 1-1.3: Product: 11g Adapter
> usb 1-1.3: Manufacturer: Ralink
> usb 1-1.3: SerialNumber: 1.0
> usb 1-1.3: configuration #1 chosen from 1 choice
>
> Other devices like usb mass storage devices work smoothly as well as
> usb mice and keyboards. This happens with the usb wireless adapter
> that I have tested.
>
> I'm not sure if the problem is because I have old versions of
> udev/kernel/libc or if I'm missing something.
> Any ideas/hints?
Udev is not involved in detecting any device, it does not make things
show up in /sys. It might only load a kernel module, by just blindly
calling modprobe for all devices which could possibly have a driver.
To check that you can just call modprobe manually.
There is no other logic in userspace. All the other stuff, which makes
devices to show up is inside the kernel, not in userspace.
Kay
^ permalink raw reply
* Re: udev seems to not recognize some devices when plugging them
From: Greg KH @ 2010-10-13 13:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTimRDapMMB3+v2YNF6TrLn3B4+RnZYmBzUseGYuh@mail.gmail.com>
On Wed, Oct 13, 2010 at 11:34:45AM +0200, Pedro Aguilar wrote:
> Hi,
>
> I'm working on a set-top-box that needs a wireless network using an
> usb wireless adapter such as the d-link dwl-122 that is supported
> under Linux.
> I have a kernel 2.6.23.17, libc 2.6 and udev 129. For several reasons
> I cannot upgrade the kernel :(
>
> My problem is that after compiling the kernel with all the necessary
> wireless modules (like mac80211), compiling and insmoding the usb
> wireless driver (rt73), copying its fw, and connecting the usb
> adapter, I have the following behaviour:
>
> There isn't any change in /sys/. I would expect a new dir in
> /sys/class/net (something like /sys/class/net/wlan0).
> # ls /sys/class/net/
> eth0 lo
>
> If I write a 00-test.rules, when I connect the usb adapter it matches
> and calls the test.sh script.
> ACTION="add", SUBSYSTEM="usb", ATTR{idVendor}="07d1",
> ATTR{idProduct}="3c0f", RUN+="/usr/bin/test.sh"
> so I think the kernel is sending the event to udev, but I don't see
> any net iface.
>
> iwconfig doesn't give any wireless interface:
> # iwconfig
> eth0 no wireless extensions.
> lo no wireless extensions.
>
> lsusb and cat /proc/bus/usb/devices give the right ouput:
> # lsusb
> Bus 001 Device 011: ID 07d1:3c0f D-Link System
> ...
>
> # cat /proc/bus/usb/devices
> T: Bus\x01 Lev\x02 Prnt\x02 Port\x02 Cnt\x01 Dev#= 11 SpdH0 MxCh= 0
> D: Ver= 2.00 Cls\0(>ifc ) Sub\0 Prot\0 MxPSd #Cfgs= 1
> P: Vendor\ad1 ProdID<0f Rev= 1.01
> S: Manufacturer=Ralink
> S: Product\x11g Adapter
> S: SerialNumber=1.0
> C:* #Ifs= 1 Cfg#= 1 Atr€ MxPwrE0mA
> I:* If#= 0 Alt= 0 #EPs= 7 Clsÿ(vend.) Subÿ Protÿ Driver=(none)
The problem is you don't have a driver bound to this device at all, so
there's nothing for udev, or anything else in userspace to be able to
control or notice.
Are you sure you have built the rt2x00 driver in your kernel? That
driver will control this device on the latest kernel versions.
good luck,
greg k-h
^ permalink raw reply
* Re: udev seems to not recognize some devices when plugging them
From: Pedro Aguilar @ 2010-10-14 17:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTimRDapMMB3+v2YNF6TrLn3B4+RnZYmBzUseGYuh@mail.gmail.com>
Hi,
I built the rt2x00 as modules from compat-wireless-old-2009-12-11
since it has support for the kernel 2.6.23.17.
After building the kernel with the right options (that were required
by compat-wireless-old) I insmoded the modules in this order
ieee80211_crypt.ko
ieee80211.ko
cfg80211.ko
mac80211.ko
rt2x00lib.ko
rt2x00usb.ko
rt2500usb.ko
rt73usb.ko
but it still seems to not have a driver bound for this device, I don't
see any changes in /sys/class/net, only the usb subsystem shows
something inside /sys/bus/usb .
I have the same problem with other devices (not usb wireless adapters)
so may be I could be missing some kernel configurations parameters.
However, as I mentioned before, mass storage and i/o devices work as
expected.
Do you have any ideas what could cause the kernel not to bound a
driver to a device even though the driver exists?
Thanks again for your support!
Regards,
--
Pedro Aguilar
http://www.paguilar.org/blog
On Wed, Oct 13, 2010 at 3:40 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Oct 13, 2010 at 11:34:45AM +0200, Pedro Aguilar wrote:
>> Hi,
>>
>> I'm working on a set-top-box that needs a wireless network using an
>> usb wireless adapter such as the d-link dwl-122 that is supported
>> under Linux.
>> I have a kernel 2.6.23.17, libc 2.6 and udev 129. For several reasons
>> I cannot upgrade the kernel :(
>>
>> My problem is that after compiling the kernel with all the necessary
>> wireless modules (like mac80211), compiling and insmoding the usb
>> wireless driver (rt73), copying its fw, and connecting the usb
>> adapter, I have the following behaviour:
>>
>> There isn't any change in /sys/. I would expect a new dir in
>> /sys/class/net (something like /sys/class/net/wlan0).
>> # ls /sys/class/net/
>> eth0 lo
>>
>> If I write a 00-test.rules, when I connect the usb adapter it matches
>> and calls the test.sh script.
>> ACTION="add", SUBSYSTEM="usb", ATTR{idVendor}="07d1",
>> ATTR{idProduct}="3c0f", RUN+="/usr/bin/test.sh"
>> so I think the kernel is sending the event to udev, but I don't see
>> any net iface.
>>
>> iwconfig doesn't give any wireless interface:
>> # iwconfig
>> eth0 no wireless extensions.
>> lo no wireless extensions.
>>
>> lsusb and cat /proc/bus/usb/devices give the right ouput:
>> # lsusb
>> Bus 001 Device 011: ID 07d1:3c0f D-Link System
>> ...
>>
>> # cat /proc/bus/usb/devices
>> T: Bus\x01 Lev\x02 Prnt\x02 Port\x02 Cnt\x01 Dev#= 11 SpdH0 MxCh= 0
>> D: Ver= 2.00 Cls\0(>ifc ) Sub\0 Prot\0 MxPSd #Cfgs= 1
>> P: Vendor\ad1 ProdID<0f Rev= 1.01
>> S: Manufacturer=Ralink
>> S: Product\x11g Adapter
>> S: SerialNumber=1.0
>> C:* #Ifs= 1 Cfg#= 1 Atr€ MxPwrE0mA
>> I:* If#= 0 Alt= 0 #EPs= 7 Clsÿ(vend.) Subÿ Protÿ Driver=(none)
>
> The problem is you don't have a driver bound to this device at all, so
> there's nothing for udev, or anything else in userspace to be able to
> control or notice.
>
> Are you sure you have built the rt2x00 driver in your kernel? That
> driver will control this device on the latest kernel versions.
>
> good luck,
>
> greg k-h
>
^ permalink raw reply
* Re: udev seems to not recognize some devices when plugging them
From: Jim Paris @ 2010-10-14 17:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTimRDapMMB3+v2YNF6TrLn3B4+RnZYmBzUseGYuh@mail.gmail.com>
Pedro Aguilar wrote:
> Hi,
>
> I built the rt2x00 as modules from compat-wireless-old-2009-12-11
> since it has support for the kernel 2.6.23.17.
> After building the kernel with the right options (that were required
> by compat-wireless-old) I insmoded the modules in this order
>
> ieee80211_crypt.ko
> ieee80211.ko
> cfg80211.ko
> mac80211.ko
> rt2x00lib.ko
> rt2x00usb.ko
> rt2500usb.ko
> rt73usb.ko
>
> but it still seems to not have a driver bound for this device, I don't
> see any changes in /sys/class/net, only the usb subsystem shows
> something inside /sys/bus/usb .
>
> I have the same problem with other devices (not usb wireless adapters)
> so may be I could be missing some kernel configurations parameters.
> However, as I mentioned before, mass storage and i/o devices work as
> expected.
>
> Do you have any ideas what could cause the kernel not to bound a
> driver to a device even though the driver exists?
>
> Thanks again for your support!
(Please don't top-quote)
The drivers in compat-wireless-old-2009-12-11 don't support your device:
pilot:/tmp/compat-wireless-2.6-old$ grep -ir 0x07d1 .
./drivers/net/wireless/ar9170/main.c: { USB_DEVICE(0x07d1, 0x3c10) },
./drivers/net/wireless/rt2x00/rt73usb.c: { USB_DEVICE(0x07d1, 0x3c03), USB_DEVICE_DATA(&rt73usb_ops) },
./drivers/net/wireless/rt2x00/rt73usb.c: { USB_DEVICE(0x07d1, 0x3c04), USB_DEVICE_DATA(&rt73usb_ops) },
./drivers/net/wireless/rt2x00/rt73usb.c: { USB_DEVICE(0x07d1, 0x3c06), USB_DEVICE_DATA(&rt73usb_ops) },
./drivers/net/wireless/rt2x00/rt73usb.c: { USB_DEVICE(0x07d1, 0x3c07), USB_DEVICE_DATA(&rt73usb_ops) },
pilot:/tmp/compat-wireless-2.6-old$ grep -ir 0x3c0f .
pilot:/tmp/compat-wireless-2.6-old$
I don't think your chipset is supported by those drivers. Really,
upgrading your kernel would be the best solution. This really isn't
related to udev at all.
-jim
^ permalink raw reply
* Re: udev seems to not recognize some devices when plugging them
From: Greg KH @ 2010-10-14 18:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTimRDapMMB3+v2YNF6TrLn3B4+RnZYmBzUseGYuh@mail.gmail.com>
On Thu, Oct 14, 2010 at 07:04:59PM +0200, Pedro Aguilar wrote:
> Hi,
>
> I built the rt2x00 as modules from compat-wireless-old-2009-12-11
> since it has support for the kernel 2.6.23.17.
Is that the kernel version you are stuck with?
That's the issue, please upgrade to a newer, modern kernel version
(yours is more than 3 years old, before the hardware you are trying to
use was around.)
good luck,
greg k-h
^ permalink raw reply
* Rule file requires "touch" to set group after restart.
From: Hawkeye King @ 2010-10-14 21:36 UTC (permalink / raw)
To: linux-hotplug
Hello,
I'm having a problem with a udev rule for a custom USB IO board.
After a reboot, the group ownership will not be set, unless I
"touch /etc/udev/rules/10-BRL_USB.rules"
Has anyone seen this before? Can you tell me what's going wrong and
how to fix it the "right" way?
Here is the rule, which is installed at /etc/udev/rules/10-BRL_USB.rules
SUBSYSTEMS="usb",ATTRS{manufacturer}="UW BioRobotics
Lab",NAME="brl_usb_%s{serial}",GROUP="devgroup",MODEw7
Here is the sequence of events I'm talking about. Notice that the
group ownership is updated the second time the device is powered on:
<< computer restarted, device powered on >>
[user@host usb_driver]$ ls -l /dev/brl*
crw-rw---- 1 root root 180, 192 2010-10-14 13:31 /dev/brl_usb_6
[user@host usb_driver]$ sudo touch
/etc/udev/rules.d/10-BRL_USB.rules
Password:
<< device is turned off, then on again >>
[user@host usb_driver]$ ls -l /dev/brl*
crw-rw---- 1 root devgroup 180, 192 2010-10-14 13:48 /dev/brl_usb_6
I think I have udev version 118, on Fedora 8.
Any help is appreciated!
Sincerely,
Hawkeye
BioRobotics Laboratory
University of Washington
Seattle
http://brl.ee.washington.edu
^ permalink raw reply
* Re: Rule file requires "touch" to set group after restart.
From: Greg KH @ 2010-10-15 1:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikBF8s1wejMC34Uvo=_RBqyWnNGp42UfZ1bph=q@mail.gmail.com>
On Thu, Oct 14, 2010 at 02:36:55PM -0700, Hawkeye King wrote:
> I think I have udev version 118, on Fedora 8.
I don't think Fedora 8 is supported anymore, why not upgrade to a modern
release?
thanks,
greg k-h
^ permalink raw reply
* Re: Rule file requires "touch" to set group after restart.
From: Hawkeye King @ 2010-10-15 19:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikBF8s1wejMC34Uvo=_RBqyWnNGp42UfZ1bph=q@mail.gmail.com>
On Oct 14, 2010, at 6:17 PM, Greg KH wrote:
> On Thu, Oct 14, 2010 at 02:36:55PM -0700, Hawkeye King wrote:
>> I think I have udev version 118, on Fedora 8.
>
> I don't think Fedora 8 is supported anymore, why not upgrade to a modern
> release?
>
> thanks,
>
> greg k-h
Dear Greg,
The install I have now (mostly) works, and therefore I don't want to fix it! At least not right now. =D
I think I've found the cause of the problem: the host uses a NIS login server and that is serving the group info. If I specify a local group, then the device group ownership is set properly.
I discovered this after testing on an Ubuntu 10.10 box that isn't connected to the NIS server, so thank you for a helpful hint!
Best regards,
Hawkeye
---------------------------
H. Hawkeye King, MSEE
Dept. of Electrical Engineering
University of Washington
Seattle, WA, USA
http://brl.ee.washington.edu
^ permalink raw reply
* Re: [RFD] Device Renaming Mechanism
From: Nao Nishijima @ 2010-10-18 11:43 UTC (permalink / raw)
To: Greg KH, kay.sievers
Cc: James.Bottomley, rwheeler, linux-kernel, linux-hotplug,
masami.hiramatsu.pt, Matt_Domsch
In-Reply-To: <20101008204802.GA21542@kroah.com>
Hello,
(2010/10/09 5:48), Greg KH wrote:
>
>> Udev makes persistent symbolic links(by-{id, uuid, path, label}) pointing to each
>> device based on device information. Applications access the device via these
>> symbolic links. Udev solves mismatch between device name and physical disk.
>> However the persistent name mismatches kernel's device name.
>> This mismatch causes following 4 issues.
>>
>> Issue 1: /proc/partitions, /proc/diskstat gives you device names
>> We have to run "ls -l /dev/disk/by-*" or "udevadm" for finding corresponding
>> persistent symbolic links.
>
> That's fine, don't use the /proc files :)
I think that the tool which displays persistent names instead of device names,
is necessary for uses who use persistent symbolic links.
>
>> Issue 2: dmesg output device name instead of persistent symbolic links
>> Users might not know which disk is sdX, because they identify the disk by a
>> persistent symbolic link.
>
> Again, that's fine as well, don't use "raw" dmesg output and expect it
> to map to what the user has mounted. There are a number of tools to
> handle the mapping of this out there by companies (IBM, CA, etc.)
>
Are these tools released under open source license? (IOW, anyone who uses linux
can use it?) If not, we should provide a tool under open source license, because
I think that it is necessary to solve the issue of OSS kernel with OSS tool.
>> Issue 3: Some system commands don't accept symbolic link(e.g. df, iostat,...)
>> These commands just expect sdX device name or check input by /proc information.
>> This will also occur on several GNOME/KDE/etc GUI sysadmin tools. :(
>
> Then we should fix those programs, it is a simple one line change. Can
> you please tell us which programs you have tested and found problems
> with?
>
Persistent symbolic links cannot be used for the argument of following commands.
"smartctl", "sgpio", "grub-isntall", "iostat". And we should have to fix a
number of commands which use device name for output, because those commands do
not show persistent device name.
>> Issue 4: Undecided symbolic link
>> Even if we would like to introduce device names/persistent symbolic links
>> mapping tool to solve it, we can not determine a symbolic link from a device,
>> because several symbolic links point a device file.
>
> Huh? You want to move from a kernel name to the one that the user used?
> As you are the user, you should know which one you used :)
>
On a multi-admin system, an admin may not be able to know which name
has been used by others. Of course, that case might be finally handled
by themselves. But from the viewpoint of fool-proof, current solution
is easy to lead that situation.
>> Therefore, I think the symbolic link is not enough to solve. We need a
>> better solution.
>
> I strongly disagree.
>
>> Proposal
>> ====
>> I'd like to propose introducing device renaming interface to solve these issues.
>
> Ick, no, please, no.
>
>> I think renaming device name in the kernel is the simplest way to solve mismatch
>> dmesg and /proc information. This can be done while kernel booting up(like
>> ifcfg). Of course, udev still needs to assign new name for each device via that
>> interface.
>>
>> This proposal just requests to add a simple interface to kernel as below. And we
>> can continue to use user program without any modification.
>>
>> int rename_device(const char *newname, const char *oldname)
>
> I'll quote a message that Kay wrote to me last week when I told him
> about this talk. It's why we don't want to rename kernel devices, and
> why using symlinks are the way to go:
>
> - All links or nodes can be stat()'d an then /sys/dev/block/M:m
> points to the kernel. So easy!
>
Hmm, agreed
> - Libudev provides all device meta information, list of links,
> events. No app/management tool can ever work properly in 2010
> that does not react on hotplug or device update events. 1980
> is over, we are all 100% hotplug aware, or we die!
>
Yes.
> - Kernel device renaming is very fragile and only done for
> netdevs because they can't have symlinks. There are many
> cross-refs for blockdevs like holders/ slaves/ sysfs dirs,
> they all need to be renamed atomically and race-free, which is
> almost impossible I would say.
>
> - Biggest problem with renaming is that the device gets
> advertised and is accessed immediately by userspace. Renaming
> after advertising (sysfs, devtmpfs, uevent) is very difficult,
> racy, almost impossible.
>
I agree that renaming after advertising to be difficult, but network goes well?
> - The only option to have named block devs is to have change the
> block layer to create intermediate devices in sysfs (which are
> advertised but not accessible as blockdevs) and then let
> userspace hook into it and request a real blockdev with a
> specified name, and only _after_ this create the real
> blockdev. This is, and must be, not a renaming, but a naming.
>
It sounds good to me. but i don't understand clearly.
Is "Not accessible as blockdevs" meaning that a device not register
bdi(backing_dev_info) list or Major/miner not given to device?
Could you tell me in detail?
> Kay said he had lots more reasons why this shouldn't be done, if you
> want them as well :)
>
> Also, note that the network people are really wanting symlinks these
> days, and the fact that renaming the device can cause problems, so
> please don't look to them as the "correct" solution at all.
>
I think that network people will face the same mismatch problems because they
use symlinks. I understand that renaming is a problem. I'd like to try Kay's idea.
> Hope this helps,
>
> greg k-h
>
Thank you for your advice.
Best Regards,
--
Nao NISHIJIMA
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
Email： nao.nishijima.xt@hitachi.com
^ permalink raw reply
* Re: [RFD] Device Renaming Mechanism
From: Kay Sievers @ 2010-10-18 12:33 UTC (permalink / raw)
To: Nao Nishijima
Cc: Greg KH, James.Bottomley, rwheeler, linux-kernel, linux-hotplug,
masami.hiramatsu.pt, Matt_Domsch
In-Reply-To: <4CBC32CC.6010506@hitachi.com>
On Mon, Oct 18, 2010 at 13:43, Nao Nishijima
<nao.nishijima.xt@hitachi.com> wrote:
>> - Kernel device renaming is very fragile and only done for
>> netdevs because they can't have symlinks. There are many
>> cross-refs for blockdevs like holders/ slaves/ sysfs dirs,
>> they all need to be renamed atomically and race-free, which is
>> almost impossible I would say.
>>
>> - Biggest problem with renaming is that the device gets
>> advertised and is accessed immediately by userspace. Renaming
>> after advertising (sysfs, devtmpfs, uevent) is very difficult,
>> racy, almost impossible.
>>
>
> I agree that renaming after advertising to be difficult, but network goes well?
Not at all. It's a complete mess I wouldn't recommend doing. Udev's
default does this for the common case, but it has many cases where
stuff just goes wrong and can never be solved properly.
Netif names need to be swapped sometimes, and then you need temporary
renaming to a non-clashing name, and sleep() until the desired name
becomes available. During all that, the netlink messages announce all
these changes/new names to possible applications. Uevents get out of
sync, the devpaths of devices swap around.
In short: it's a complete nightmare from the view of reliability, and
I strongly suggest not even to think about to try that model on any
other subsystem.
>> - The only option to have named block devs is to have change the
>> block layer to create intermediate devices in sysfs (which are
>> advertised but not accessible as blockdevs) and then let
>> userspace hook into it and request a real blockdev with a
>> specified name, and only _after_ this create the real
>> blockdev. This is, and must be, not a renaming, but a naming.
>>
>
> It sounds good to me. but i don't understand clearly.
> Is "Not accessible as blockdevs" meaning that a device not register
> bdi(backing_dev_info) list or Major/miner not given to device?
> Could you tell me in detail?
It's all about the userspace visible device state. You can't export a
blockdev which you are going to rename shortly after this, it does
confuse usespace, and can not made work reliably.
How it's implemented inside the kernel does not really matter for the
outside as long as it has a step for userspace to provide the name,
that is used to create(not rename) and announce the device with.
It would need to be some intermediate device, which is not a blockdev,
and has no dev_t assigned, and exports needed metadata to compose a
device name from it. This name is then used to create the real
blockdev.
Note, that I'm not suggesting to do anything like that. It would just
be the only model that *could* be made working. The way network
interfaces are handled must not be applied to other subsystems.
Things like device-mapper could probably get a reasonable way to
provide a fixed name for the dm device to create. They are created by
userspace request only, they know the metadata before the request --
so this sounds feasible in some way. As long as they can not be
renamed afterwards, which can't work for many other reasons.
Device-mapper could maybe make the dm UUID mandatory, and use it as
the device name. It will break a bunch of tools, which match on device
names, but I guess it *could* be made working (if it does not involve
any later renaming).
> I think that network people will face the same mismatch problems because they
> use symlinks.
The thing is that unlike blockdevs, netif names may have meaning
inside the kernel, like matching wildcards in iptables and such. That
makes any out-of-kernel "alias"-model for netifs much more complicated
than it is for blockdevs where "aliases" only need to exist in
userspace.
> I understand that renaming is a problem. I'd like to try Kay's idea.
I wouldn't even try. Besides the mentioned device mapper
mandatory/non-changeable UUID=device-name approach which could work,
I don't think that renaming of sd devices can be made working, without
rewriting half of all existing userspace. :)
Kay
^ permalink raw reply
* Re: udev seems to not recognize some devices when plugging them
From: Pedro Aguilar @ 2010-10-19 14:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTimRDapMMB3+v2YNF6TrLn3B4+RnZYmBzUseGYuh@mail.gmail.com>
Hi,
I bought the supported hw revision of the d-link dwl-122 usb wireless
adapter that is C1 (I was using E1) and with the
compat-wireless-old-2009-12-11 it worked, but only with an unencrypted
connection that is not very useful. I still had problems with the
kernel when trying to establish a wpa2-based connection, so at the end
I'm upgrading the kernel as you suggested.
Thanks a lot for your help!
--
Pedro Aguilar
http://www.paguilar.org/blog
On Thu, Oct 14, 2010 at 8:19 PM, Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 14, 2010 at 07:04:59PM +0200, Pedro Aguilar wrote:
>> Hi,
>>
>> I built the rt2x00 as modules from compat-wireless-old-2009-12-11
>> since it has support for the kernel 2.6.23.17.
>
> Is that the kernel version you are stuck with?
>
> That's the issue, please upgrade to a newer, modern kernel version
> (yours is more than 3 years old, before the hardware you are trying to
> use was around.)
>
> good luck,
>
> greg k-h
>
^ permalink raw reply
* udev permissions for USB
From: Alan Stern @ 2010-10-20 14:07 UTC (permalink / raw)
To: linux-hotplug
Forwarding this message to the linux-hotplug mailing list.
Alan Stern
On Wed, 20 Oct 2010, Xiaofan Chen wrote:
> On Wed, Oct 20, 2010 at 5:54 AM, Peter Stuge <peter@stuge.se> wrote:
> > Tim Roberts wrote:
> >> ACTION="add", SUBSYSTEM="usb_device", SYSFS{idVendor}="hhhh", MODE="666"
> >
> > Please note that 666 is never a good mode to use. It means that every
> > user in the system has direct access to the hardware device. In
> > practise it removes all security from the system.
> >
> > Please make use of relevant groups, and use a mode like 660 or
> > ideally only allow a single user access with mode 600.
>
> I think your recommendation is good. Unfortunately
> the default udev rule for libusb device is not
> really following your recommendation.
>
> >From udev 163 release's 50-udev-default.rules.
> # libusb device nodes
> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>
> I wonder if this is better changed to using the "usb" or "plugdev"
> group and "0660". Then it is quite easy to ask the user to
> add them to the "usb" or "plugdev" group in order to use libusb
> based application as non-root user.
^ permalink raw reply
* Re: udev permissions for USB
From: Kay Sievers @ 2010-10-22 14:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1010201004360.1626-100000@iolanthe.rowland.org>
On Wed, Oct 20, 2010 at 16:07, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 20 Oct 2010, Xiaofan Chen wrote:
>
>> On Wed, Oct 20, 2010 at 5:54 AM, Peter Stuge <peter@stuge.se> wrote:
>> > Tim Roberts wrote:
>> >> ACTION="add", SUBSYSTEM="usb_device", SYSFS{idVendor}="hhhh", MODE="666"
>> >
>> > Please note that 666 is never a good mode to use. It means that every
>> > user in the system has direct access to the hardware device. In
>> > practise it removes all security from the system.
>> >
>> > Please make use of relevant groups, and use a mode like 660 or
>> > ideally only allow a single user access with mode 600.
>>
>> I think your recommendation is good. Unfortunately
>> the default udev rule for libusb device is not
>> really following your recommendation.
>>
>> >From udev 163 release's 50-udev-default.rules.
>> # libusb device nodes
>> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>>
>> I wonder if this is better changed to using the "usb" or "plugdev"
>> group and "0660". Then it is quite easy to ask the user to
>> add them to the "usb" or "plugdev" group in order to use libusb
>> based application as non-root user.
Users are not put into any groups for device access these days.
Certain classes of USB devices like printers, fingerprint readers,
scanners, webcams, ... get ACLs assigned for locally logged-in users
only.
Group permissions on devices can be used from remote-logins which
needs to be prevented for security reasons, like you don't want
anybody logged-in over ssh to enable your webcam, or listen to your
sound card.
Kay
^ permalink raw reply
* [ANNOUNCE] udev 164 release
From: Kay Sievers @ 2010-10-24 14:43 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 164
====
Bugfixes.
GUdev moved from /usr to /.
^ permalink raw reply
* Re: udev permissions for USB
From: Xiaofan Chen @ 2010-10-25 3:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1010201004360.1626-100000@iolanthe.rowland.org>
On Fri, Oct 22, 2010 at 10:10 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Oct 20, 2010 at 16:07, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Wed, 20 Oct 2010, Xiaofan Chen wrote:
>>> >From udev 163 release's 50-udev-default.rules.
>>> # libusb device nodes
>>> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>>>
>>> I wonder if this is better changed to using the "usb" or "plugdev"
>>> group and "0660". Then it is quite easy to ask the user to
>>> add them to the "usb" or "plugdev" group in order to use libusb
>>> based application as non-root user.
>
> Users are not put into any groups for device access these days.
>
> Certain classes of USB devices like printers, fingerprint readers,
> scanners, webcams, ... get ACLs assigned for locally logged-in users
> only.
>
> Group permissions on devices can be used from remote-logins which
> needs to be prevented for security reasons, like you don't want
> anybody logged-in over ssh to enable your webcam, or listen to your
> sound card.
>
I wonder if the default udev rule for libusb device (Mode 0664) follow your
reasoning. I do not think group based rule (Mode 0660 and using "plugdev"
group) is any worse than the default libusb udev rule for remote logged-in
users.
And there are plenty of group based rules in 50-udev-default.rules,
like sound, video and firewire device.
Eg: all the lines above the default libusb rules.
# sound
SUBSYSTEM="sound", GROUP="audio"
KERNEL="mixer0", SYMLINK+="mixer"
# DVB (video)
SUBSYSTEM="dvb", GROUP="video"
# FireWire (firewire-core driver: IIDC devices, AV/C devices)
SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x00010*", GROUP="video"
SUBSYSTEM="firewire", ATTR{units}="*0x00b09d:0x00010*", GROUP="video"
SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x010001*", GROUP="video"
SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x014001*", GROUP="video"
# libusb device nodes
SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
Am I missing something obvious here?
--
Xiaofan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox