[Bug 236990] Re: samba hasn't been working with 2 logins on the same server since Ubuntu hardy 8.04
Sorry, I'm really stressed at the moment ;-) Today I reported this bug to GNOME. You can find it here: http://bugzilla.gnome.org/show_bug.cgi?id=559388 I tested this bug again and it still appears in Ubuntu 8.04 (Hardy Heron). But this bug does not appear in Ubuntu 8.10 (Intrepid Ibex) Live-CD! best regards -- samba hasn't been working with 2 logins on the same server since Ubuntu hardy 8.04 https://bugs.launchpad.net/bugs/236990 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 37898] Re: Ipod won't re-mount
The initial bug description shows that the kernel rediscovers the disk and its partition just fine. So it is obviously a bug in the userspace infrastructure. -- Ipod won't re-mount https://bugs.launchpad.net/bugs/37898 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-volume-manager in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
Duncan Lithgow wrote: Reopening this bug. In Ubuntu 8.10 (Alpha 6) importing dv over firewire does not just work with Kino 1.3.0 I'm back at the familiar message: WARNING: raw1394 kernel module not loaded or failure to read/write /dev/raw1394 My first guess is that this is because someone forgot to set the flag needed during the build to enable support for /dev/video1394 which is not enabled by default... No, Kino requires /dev/raw1394. Check with lsmod that the raw1394 and the ohci1394 drivers are loaded, and check the file permissions (or access control list) of /dev/raw1394. PS: As mentioned in my previous comment, alternative kernel drivers are in development which allow to implement a more flexible security policy, but I suppose these drivers are not enabled in Ubuntu 8.10 --- and they probably shouldn't because of immaturity. (The wiki which I mentioned in the other comment is now located at http://ieee1394.wiki.kernel.org/.) -- DV capture over Firewire is broken https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 152392] Re: [gutsy/hardy/intrepid] Kino can't capture video
*** This bug is a duplicate of bug 6290 *** https://bugs.launchpad.net/bugs/6290 Scott James Remnant wrote on 2008-04-24: ... The statements about IEEE 1394 and about what the linux1394 stack does are... somewhat inaccurate. I won't comment further. Failing that, an interim solution would be if we could at least have some information from the kernel about _WHAT_ is connected on the firewire port when they are connected and disconnected, we don't even get that right now! Wrong, you do get that. There are kobjects and uevents for each unit on each node, including the AV/C unit of a camcorder for example. If we had insert notification, with vendor and device ids inside the uevent, we could at least enable access on a per known device basis -- I'd still be nervous about raw1394 though, since anyone can fake a device id pair. Indeed; it doesn't make sense to use these uevents to change /dev/raw1394's ownership and permissions or ACL because the basic problems of 1.) ohci1394 having physical DMA enabled, 2.) /dev/raw1394 being used for all devices don't go away. (Both of these issues are addressed by the new firewire stack.) -- [gutsy/hardy/intrepid] Kino can't capture video https://bugs.launchpad.net/bugs/152392 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee (via bug 6290). -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 152392] Re: [gutsy/hardy/intrepid] Kino can't capture video
*** This bug is a duplicate of bug 6290 *** https://bugs.launchpad.net/bugs/6290 Scott James Remnant wrote on 2008-06-09: dv1394 is going away in the kernel :-( Nowadays I think that dv1394 will remain in the mainline as long as the ieee1394 driver stack remains in there. However, it is important to make it known that the dv1394 ABI is deprecated because there is no direct replacement for it in the new firewire stack (in contrast to the raw1394 and video1394 ABIs for which there is a migration path to firewire-core's ABI). -- [gutsy/hardy/intrepid] Kino can't capture video https://bugs.launchpad.net/bugs/152392 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee (via bug 6290). -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: DV capture over Firewire is broken
Duncan: With the camcorder attached and switched on, please save the output of dmesg into a file and attach it. Also, post the output of ls /sys/bus/ieee1394/devices/ and grep . /sys/bus/ieee1394/devices/fw-host0/* Furthermore, does Ubuntu's libraw1394 package maintainer listen here? There have been modified versions of libraw1394 v1 out there which only work with the new firewire kernel drivers but not with raw1394. I hear that Debian is somewhere in the transition from the ieee1394 drivers to the firewire drivers, and in the worst case, you might have gotten an unsuitable libraw1394 version from your upstream. Make sure that you have either a libraw1394 v1 which still works with raw1394, or libraw1394 v2 which transparently works with either driver stack. -- DV capture over Firewire is broken https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 236990] Re: samba hasn't been working with 2 logins on the same server since Ubuntu hardy 8.04
Sorry, I was absent ;-) I try to describe this problem a second time. Scenario 1: Ubuntu Gutsy 7.10 1. open nautilus 2. press the edit button so that you can type a location (e.g. /home/user/Desktop) 3. type the following address: smb://[EMAIL PROTECTED] and press return 4. now you have to log in on the server ... 5. so that you can see the folder of user1 on server 192.168.0.3 by using a samba-server 6. open a second nautilus window 7. type the following address: smb://[EMAIL PROTECTED] and press return 8. after that you have to write the password of user2 9. so now you can see the folder of user2 on the same server = everything correct Scenario 2: Ubuntu Hardy 8.04 1. open nautilus 2. press the edit button so that you can type a location (e.g. /home/user/Desktop) 3. type the following address: smb://[EMAIL PROTECTED] and press return 4. now you have to log in on the server ... (after this moment the address automatically changes to smb://192.168.0.3 = I think this is already buggy and didn't happen in scenario 1) 5. so that you can see the folder of user1 on server 192.168.0.3 by using a samba-server 6. open a second nautilus window 7. type the following address: smb://[EMAIL PROTECTED] and press return 8. after that you have to write the password of user2 9. now you can't see the folder of user2 as described in scenario 1 step 9 you only see the folder of user1 again = bug! I would be happy if this could be fixed. Don't hesitate to ask me again ;-) ** Changed in: nautilus (Ubuntu) Status: Invalid = New -- samba hasn't been working with 2 logins on the same server since Ubuntu hardy 8.04 https://bugs.launchpad.net/bugs/236990 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 236990] [NEW] samba hasn't been working with 2 logins on the same server since Ubuntu hardy 8.04
Public bug reported: Binary package hint: nautilus I think that this bug occurs in Ubuntu hardy and not in Ubuntu Gutsy. if I log in a samba server in nautilus (smb://[EMAIL PROTECTED]) I will not be able to log in the same server with another account (smb://[EMAIL PROTECTED]). Instead of showing me the files and folders of user2, I get the directory of user1. ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New -- samba hasn't been working with 2 logins on the same server since Ubuntu hardy 8.04 https://bugs.launchpad.net/bugs/236990 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
Security enhanced replacement drivers are being worked on since last year, but not yet ready for prime time. It is possible with these drivers to let scripts assign different device file permissions based on the type of FireWire device ( - finer grained device security). These drivers also implement filtered physical DMA as mentioned in a previous comment ( - improved host security). Development status of these drivers is posted at wiki.linux1394.org. Capturing DV video over the desktop should be straightforward, It actually is, except if ancient userspace software is used. -- use /dev/video1394, not /dev/raw1394 https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
Jeff, that's evidently a very old version of dvgrab. File a bug for the dvgrab package --- it should be updated to version 2.1. Yes, the dv1394 driver will eventually vanish. But there is no date set for its removal yet; it depends on how fast the new alternative FireWire stack which was merged in Linux 2.6.22 and the respective userland support will reach maturity. The unsupported isochronous request types in raw1394 that dvgrab 1.x can use alternatively to dvgrab1394 will be unavailable from Linux 2.6.23 onwards. Dvgrab 2.x as well as reasonably recent Kino versions use only supported libraw1394 calls. Dan, the link to dvgrab-2.1.tgz on the Download page at www.kinodv.org is mistakenly titled dvgrab-1.2.tar.gz. -- use /dev/video1394, not /dev/raw1394 https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
I wrote: The unsupported isochronous request types in raw1394 that dvgrab 1.x can use alternatively to dvgrab1394 should read ...to dv1394 dvgrab-2.1.tgz should read dvgrab-2.1.tar.gz -- use /dev/video1394, not /dev/raw1394 https://bugs.launchpad.net/bugs/6290 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
As I understood it, address based filtering could/would have been done with the multiple files approach too. However the capabilities based approach sounds really good. AFAICS it achieves basically the same in a simpler way. Simpler = more secure. I think the multi-file approach would allow to enable certain access only if well-known unit directories are present. But this could also be done via the capabilities based approach. It would add complexity either way; maybe actually less so if done in-kernel. However, such features could be considered later. If I look at our current track record of IEEE 1394 kernel driver maintenance, simplicity is what we need in a solution, first and foremost. (Note, I am not familiar with a lot of IEEE 1394 applications nor with Linux Capabilities.) -- use /dev/video1394, not /dev/raw1394 https://launchpad.net/bugs/6290 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
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. This feature is called physical DMA and is enabled by Linux' ohci1394 driver per default. It speeds up SBP-2. Linux' sbp2 driver does not work correctly without physical DMA at the moment. Some slides: http://md.hudora.de/presentations/#firewire-pacsec http://md.hudora.de/presentations/#firewire-21c3 Jody McIntyre's plans to improve raw1394's security: http://thread.gmane.org/gmane.linux.kernel.firewire.devel/6395/focus=6395 Neither Jody nor anybody else got around to implement these ideas yet. I hope to get sbp2 to work correctly (if slowly) without physical DMA too. Furthermore I am thinking about implementing filtered physical DMA for SBP-2. -- use /dev/video1394, not /dev/raw1394 https://launchpad.net/bugs/6290 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
Yes, you are right. Actually, a cheap setup to achieve #1 by #4 is to have two FireWire controllers in the PC and connect them. -- use /dev/video1394, not /dev/raw1394 https://launchpad.net/bugs/6290 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 6290] Re: use /dev/video1394, not /dev/raw1394
Except if you don't load ohci1394 or load ohci1394 with the parameter phys_dma=0. Switching physical DMA off will work fine with raw1394, dv1394, video1394... It will just break sbp2 until I get http://bugzilla.kernel.org/show_bug.cgi?id=6393 fixed. (It's not high on my list, and it is a nuisance to implement in an platform independent way.) I don't know if eth1394 works without physical DMA.. -- use /dev/video1394, not /dev/raw1394 https://launchpad.net/bugs/6290 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
