Note, you say "applictions", what becides vmware does not work with this?

And we don't support vmware, we can't as they use closed source kernel drivers.  They have known for a while (since 10.1 and SLES10) that this was going away, so you might just need to upgrade your version of vmware to get it to work properly.

As for security issues, it is impossible to properly set the permissions of the usb devices in the /proc/bus/usb/ directory, that is why we do not mount it anymore, and have not done so since the last release.  It is simple to just use the /dev/bus/usb/ device nodes instead, which obtain the proper permissions depending on the user that is logged into the machine.

All applications that link against libusb already work properly, so vmware should also work if it uses libusb.  If there are still problems, I suggest you contact them, as there is not much we can do about this.

So, unless you find something that we ship in our distro that breaks with this change, I'm marking this as INVALID.

That's fine for me.  I just wanted to state this because I suppose that this has the potential to draw away a really large user base from your distribution.  If you say that you don't care about potentially losing these customers to other distributions then everything is fine here.

It's not a case of "losing customers", this was a security problem that we had
to fix.  vmware is aware of this and I really think they have already fixed it
in their latest releases.

Also, because they are not part of our distro, we can not patch their code up to
get it to work properly, as I'm sure you can imagine :)

So again, just contact them, they should already have the fix for you.

I opened a bug report at their support system.

I actually didn't expect you to patch their code but I thought you might want to provide a solution that makes the /dev/bus/usb interface compabtible by providing a compatible devices file for instance. --- Note, I don't expect you to do so, I just wanted to give you a hint that you _might_ consider it.

Although I undesrstand that not all problems can be solved here I still hope your statement does not mean that we are no longer allowed to talk about problems related to applications that are not shipped with the distribution.

We did provide a solution that makes the /dev/bus/usb interface compatible
with the /proc/bus/usb/ files, that is exactly what that interface is.  And libusb makes it so that the programmer doesn't have to know which interface is on the system, it all handles it automatically for them.

So there is a way to work on all systems properly, and securely.

And sure, you can always talk about problems related to applications that are not shipped with the distro, it's just that we might not always be able to resolve them :)

You did?

Well, on my 10.2 system /dev/bus/usb does not have the devices file. So is this really available? And if this is the case: What must I configure to get it?

You don't need the devices file, all the same information is in sysfs, or you can get it from 'lsusb'.

Although I should add a "look-alike" one of these days to 'lsusb' just because it is a compact way of looking at things...

I know that you can get this information from sysfs or lsusb. But as long as you don't get it from the devices file in the same format you got it before you can't really clame the interface being compatible.

Sorry, I thought you were referring to the files that do the real work, the other /proc/bus/usb/ files, those are what matter and is what is now in /dev/bus/usb/ with the proper permissions.

Read my initial comment again. The whole report was about the devices file. I wouldn't have opened this bug otherwise because I was perfectly aware of the other files.

*** Bug 222511 has been marked as a duplicate of this bug. ***

Sorry for creating duplicate 222511 - not sure why the search on bugzilla.novell.com didn't return this ticket when searching for "CONFIG_USB_DEVICEFS".

After reading the history on this ticket, it sounds like this has turned in to a closed source verses open source debate - I hope I'm wrong.

In case I am wrong, here a couple of key points:

The current release of the VMware products (Workstation 5.5.3/Server 1.0.1) still rely on the "/proc/bus/usb" construct to provide USB functionality to virtual machines.  The belief and statements that VMware already has a fix or that an upgraded version is currently available is inaccurate.  Users upgrading to SUSE 10.2 that use VMware products and rely on VM USB functionality will find that it will not work on SUSE 10.2 without rebuilding their kernel.

The security concern with the "/proc/bus/usb" construct is valid.  As mentioned previously SUSE addressed this concern by changing the default behavior of the system to no longer mount the usbfs automatically, thus mitigating the exposure.  

Support for usbfs has not been dropped from the offical Linux kernel tree.

As the security concern only comes in to play when the "filesystem" is mounted, logically the best compromise and resolution at the moment seems to be to continue the methodology established with SUSE 10.1 which is to include USB_DEVICEFS support in the kernel build and by default to not auto-mount the usbfs filesystem.  That way users have a choice and are not forced to rebuild a kernel manually.  Unless there is a security issue with just having USB_DEVICEFS support built in to the kernel, the decision to remove it at this point seems to be arbitrary.

I don't believe anybody would expect SUSE to "support" third-party applications, but as an operating system vendor I would like to think compatibility with existing applications would always be a concern especially when releasing a new version of the operating system platform.

Yes, the security issues come into play when the filesystem is mounted, I agree.

So, we are preventing the filesystem to be mounted, in order to be more secure.

And again, this is really a vmware issue, they know about the issue and have said they have fixed it.  I suggest you contact them, as we can't even support them do to their closed source kernel modules.

*** Bug 227410 has been marked as a duplicate of this bug. ***

I ask that issue be reopened, and here is why:

I disagree with the philosophy behind your decisions to this point. I agree that usbfs is a poor design, and certainly application programmers and vendors need to move away from it. Forget them and focus on your users - if I want to use usbfs I should be able to make that choice - if you want to make your users aware that thee module is deprecated, fine - have it put a message in syslog, or make me read a warning during the OS install of the dire things that will happen if I load the module. 

Obviously, technical users can go compile their own kernels - I probably will do just that, but that's not the point.

usbfs is still present in the kernel, and all of the same functionality is still there.  In fact, if you link your program against libusb (which uses usbfs), it will automatically work with no changes needed at all.

We disabled the /proc/bus/usb/ interface as it is insecure.  We did not take away the functionality of the kernel interface, that is still there.

So, again, vmware knows about this issue and they have said they have fixed it.  As we can't support vmware because of their closed source license (both user and in kernelspace), there's nothing that we can do about it from our side.  I suggest, if you still have questions about this, to contact them.

(In reply to comment #1)
> Note, you say "applictions", what becides vmware does not work with this?

Aladdin's HASP HL USB hardware tokens also depend on usbfs. I'll notify them separately that there's a problem, but as of today they don't have updated software on their web site.

*** Bug 232042 has been marked as a duplicate of this bug. ***

*** Bug 232583 has been marked as a duplicate of this bug. ***

Hi Greg, how can i use libusb for upload firmare in usb interfaces without /proc/bus/usb?
in OSS10.1 i put firmare in /proc/bus/usb/004/002
now where i must put it?
Thanks....

_This_ part of the structure you can find in /dev/bus/usb/... now.

The same "place" as before, just use your program (which is linked against
libusb) as before.  The device nodes are now located under /dev/bus/usb/
instead of /proc/bus/usb/

Hi Greg, i tried to upload firmware in usb astribank device and first stage is ok, the second stage says: ERROR: wrong path: /dev/bus/usb/004/006
must i recompile kernel?
thanks....

What are you using to upload the firmware with?  A custom program, or the tools that come with the 10.2 release?

fxload

*** Bug 232798 has been marked as a duplicate of this bug. ***

Greg. Im pretty sure you do your job technically right, adn I thank you for that.

 but please, add some real life to it, please. if we continue this way, we will have a perfect kernel but no people using it. and then we will have no other alternative than starting to produce more unofficial kernels , alineating the userbase once again.

This change impacts the procedure documented at http://en.opensuse.org/Speedtouch_330_PPPoE as well as scripts distributed to automate the process.  :-(

(In reply to comment #28)
> This change impacts the procedure documented at
> http://en.opensuse.org/Speedtouch_330_PPPoE as well as scripts distributed to
> automate the process.  :-(
> 

To quote that page:
  The procedure in this article was written and tested with version SUSE 10.0
  Whilst there is no guarantee, it should be applicable to later versions.
  If you find this to be incorrect, please help to update this article.

*** Bug 238033 has been marked as a duplicate of this bug. ***

Removal of /proc/bus/usb also breaks pcsc-etoken on SUSE 10.2

From the package's README

This is a pcsc-lite driver ("ifdhandler v2") for
Aladdin eToken PRO (some special usb token).

Required Software:
 - pcsc-lite (www.linuxnet.com)
 - libusb (libusb.sourceforge.net)
[...]
Libusb requires (on linux) that usb is working properly.
this includes the usbdevfs mounted on /proc/bus/usb.

Again, libusb has been built to work properly, so any application linked against it will work just fine.

Do you have reports of the pcsc-etoken program not working?  Is this something that we ship in the 10.2 release?

It seems all virtual machines are affected: VirtualBox and QEmu requires usbfs.
Can we let users decide how secure / insecure they want to be?

(In reply to comment #33)
> It seems all virtual machines are affected: VirtualBox 

yes, most, either closed or open source breaks with this change.

No, we are not going to "let the user decide how secure / insecure they want to be".

QEmu and VirtualBox can use libusb and work just fine.  Neither of these are shipped by SuSE in our distro.

And no, "most" programs do not break with this change.

Please do NOT reopen this bug, it's not going to be changed.

Hi Greg!

The small fine open source tool "usbview" does not work but is shiped with SuSE v10.2. Configuring the device path from /proc/bus/usb/ to /dev/bus/usb does not work --> usbview freezes. It seems we did not have a solution which is complete compatible as you said - or we have a lack in organisation of quality assurance.

Maybe there are more broken packages in SuSE v10.2. This is a not acceptable state!

Please find a solution as soon as possible. Otherwise you will lose many users - regardless to security issues.

Sorry, I forgot to reopen the bug. :)

Andreas, how do expect quality assurance if employees couldn't even see that qemu _is_ actually shipped with their distribution? ;-)

Honestly I believe that this is more or less some religious thing for Greg.  Thus a discussion on a technical level does not seem to make sense here.  And since you can learn from comment #3 Novell does not care about losing customers/users due to this problem, if you need to use products using usbdevfs it is currently best choice to switch to a different distribution vendor.

BTW: Actually the security argument does not make any sense at all because in practice there are two classes of users:

1. Users that _don't_ run applications using /proc/bus/usb/devices.  Those users will not mount /proc/bus/usb if it is disabled by default and then there is no issue for them.

2. Users that _do_ run such applications.  Those users are forced now to use a custom kernel.  When they do so they have again USBDEVFS with all its security concerns and additionally might miss the official kernel security updates provided by Novell.  Because of that reasons those users run an even _more_ insecure system.

Trying to _enforce_ security that way is pointless anyway.  If you were consequent in that way you had to patch chmod from the distribution to disallow setting the SUID bit because it is a security risk if someone uses this to set the SUID bit on arbitrary binaries.

If there is an issue with qemu and usbview, please file new bugs and assign them to me and I will work on resolving them.

As for the 'devices' file, yes, you are correct, the loss of it is different, but the main reason for the change is the usbfs access files, which are properly handled now through /dev.  All of the needed information in the devices file can be found in sysfs.  I've even offered to make an option for 'lsusb' to generate this format if anyone needs it.

So, again, I'm closing this bug.  If there are new applications that are found to not work, please create new bugs.

There is already a bug about usbview: Bug 228412

And qemu is now bug #241950.

*** Bug 253040 has been marked as a duplicate of this bug. ***

Ah, I raised the dupe above (sorry).  I particularly wanted usbview.

rethinking this...

Ok, it turns out that vmware doesn't want to change anything, so I'm enabling this config option now.  It will show up in the next "Kernel of the day" if anyone wants to grab that and test it.

It will still require you to mount usbfs on your own either by hand:
  mount -t usbfs none /proc/bus/usb/
or by adding the fstab entry to /etc/fstab for usbfs.  But then vmware should start working again and you don't have to rebuild your kernel.

Very sorry for all of the noise about this, I'm sorry for wasting everyone's time.

That was quick.  Thanks very much!

Thanks for finally fixing this.

I hope you also re-enable usbfs in the next 10.2 update kernel...

Ok, and where do I find the "kernel of the day" ?

http://en.opensuse.org/Additional_YaST_Package_Repositories#Update_Packages_without_a_YaST_Repository

What I did was to compile my own version of the stable kernel.  It was surprisingly easy - install kernel source, go to /usr/src/linux, make cloneconfig, make menuconfig, select the usb file system, make, make modules_install, make install.

Sorry, the above is not very clear, but look here - 
ftp://ftp.suse.com/pub/projects/kernel/kotd/

(In reply to comment #49)
> Thanks for finally fixing this.
> 
> I hope you also re-enable usbfs in the next 10.2 update kernel...
> 

As it is not easy for me to compile my own kernel or to install a "kernel of the day", I also vote for the option CONFIG_USB_DEVICEFS to be add to the next kernel update.

I rather like to wait for a few days or weeks and get it properly installed instead of spending one week trying to compile, to crash my suse in the end...

So I hope the next update will include the option.

How can I check if the option is configured in the kernel updated ??

Thanks for the work that all of you have done ! Suse is a wonderfull OS !

Marc

Thanks for CONFIG_USB_DEVICEFS enabling.... It will REALLY ease my life with VirtualBox !

So, If I understand you correctly, this will be shipped with openSUSE 10.3, but disabled by default ?

*** Bug 263908 has been marked as a duplicate of this bug. ***

For the record: another third-party application that crucially depends on usbfs to be enabled in the kernel is the "Altera Quartus II" FPGA development environment, which includes support for the USB-Blaster FPGA programming cable:

  http://www.altera.com/support/software/drivers/dri-usb_b-lnx.html

I very much hope that the next kernel update for openSUSE 10.2 will have CONFIG_USB_DEVICEFS reenabled. Thanks!

Hey Geniuses,

Is usbfs turned on in the current openSUSE 10.2 ISOs? I just downloaded and installed openSUSE 10.2 and can't access my memory stick.

MoronIac:/media # dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 13
usb 2-1: new device found, idVendor=058f, idProduct=6362
usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1: Product: Mass Storage Device
usb 2-1: Manufacturer: Generic
usb 2-1: SerialNumber: 058F312D81A
usb 2-1: configuration #1 chosen from 1 choice

MoronIac:/media # lsusb
Bus 002 Device 013: ID 058f:6362 Alcor Micro Corp.

MoronIac:/media # mount -t usbfs /dev/bus/usb/002/013 stick
mount: unknown filesystem type 'usbfs'

Must I compile my kernel to fix this issue?

Monkey,
Dale E. Moore
PS: I thought 10.2 ISOs would be fixed since 3/9.

This was fixed via Online Update. The ISOs are unchanged.