On Wed, Jan 22, 2014 at 12:45 PM, Carsten Haitzler <[email protected]>wrote:
> > On 01/22/2014 07:33 PM, Negreanu, Adrian M wrote: > > > > > On Wed, Jan 22, 2014 at 11:18 AM, Carsten Haitzler <[email protected] > > wrote: > >> >> On 01/22/2014 06:10 PM, Negreanu, Adrian M wrote: >> >> >> >> >> On Wed, Jan 22, 2014 at 10:55 AM, Carsten Haitzler < >> [email protected]> wrote: >> >>> >>> On 01/22/2014 05:46 PM, Negreanu, Adrian M wrote: >>> >>> >>> >>> >>> On Wed, Jan 22, 2014 at 1:58 AM, Carsten Haitzler >>> <[email protected]>wrote: >>> >>>> On Tue, 21 Jan 2014 11:28:03 -0800 Ryan Ware <[email protected]> >>>> said: >>>> >>>> > Tue, Jan 21, 2014 at 2:01 AM, Jussi Laako < >>>> [email protected]>wrote: >>>> > >>>> > > On 21.1.2014 10:38, José Bollo wrote: >>>> > > >>>> > >> IMHO, SDB is integrated with the developer tools and that is really >>>> > >> good. But it is not sure at all: you can become root on the device >>>> > >> without being asked for any password, just a USB cable is needed. >>>> Also >>>> > >> SDB is a component that is not common, not proven, not linked to >>>> PAM, >>>> > >> and, that must be maintained at our cost. Just my 2 coins. >>>> > >> >>>> > > >>>> > > SDB should require enabling developer mode on the device itself, it >>>> > > shouldn't be enabled by default. Just like ADB (or whatever it was >>>> called) >>>> > > on my Android devices. I've enabled it once to flash CyanogenMOD. >>>> > > >>>> > >>>> > SDB should definitely not be on by default. Doing so goes against a >>>> number >>>> > of different security principals including reducing attackable >>>> surface area >>>> > and least privilege. >>>> >>>> sure - but same applies for ssh. the difference is that when i enable >>>> developer >>>> mode on my device. do some work, go to lunch with my phone and someone >>>> borrows >>>> it for 10 mins (plugs into usb and starts messing around) they can do >>>> so with no >>>> auth at all. zero. if sdb were to turn off every time a phone is >>>> unplugged >>>> we'll have insanely annoyed developers continually finding menus to >>>> turn it on >>>> and eventually deciding tizen is is more pain than anything else. >>>> >>> How about being asked for a password when the USB cable is plugged in ? >>> For Android, you get a notification and you can choose whether you >>> enabled debug mode or not, >>> which as you say, is not safe. >>> Instead, you may be asked for a developer password and avoid digging >>> through menus. >>> Also, I find sdbd useful when bringing up new platforms, where network >>> connectivity is not ready yet. >>> >>> >>> how is network connectivity not there? usb network gadget has been in >>> the kernel as long as i've been doing phone stuff (since at least 2008). >>> the kernel emulates a network usb device. you don't need wifi and other >>> network. >>> >> I think we're viewing the problem from two different point of views. >> I'm more interested in a device in the "bring-up" stage where you might >> not have OTG ready(thus no USB gadgets), >> whereas (I assume) you're interested in a device that's well after the >> "bring-up" stage. >> For the latter, when everything works fine, SDBD is indeed optional. >> >> >> but sing sdb uses the same usb gadget interface to advertise >> effectively what is a serial device over usb (i don't know it's details - >> but it must logically appear as some custom type/class of usb device) .. >> thus it has the same basic requirements of a kernel at this level? sure - >> you dont need userspace to CONFIGURE the usbnet device (ip address, route >> etc.) for sdb and that is indeed simpler at this stage - but at the >> usb/kernel level isn't it basically the same? >> > True, the ADB/SDB driver is a serial usb gadget. I assumed that you were > talking to plugin in an ethernet-over-usb dongle > into the phone, but that obviously wasn't the case. > > I dug up some more to see why my device wasn't found as an usb0 device and > it turned out I didn't specified > "rndis" in usb_mode/usb0/functions (my bad). > > > yeah - i was just thinking raw usb cable from device to host. same thing > sdb uses/needs. :) > > > > >> >> >>> >>> as for password - ask on the device screen? >>> >> Yup, on the device screen. This means that when I'm not in graphical >> run-level, I can use SDBD w/o being asked for >> a password. >> >> >> i suspect that woould become most infuriating to have to enter it every >> time on the phone rather than via the far more useful keyboard i have in >> front of me right now ... :) >> > true. considering "i can has" network in the bring-up stage, this isn't > needed anymore > Though, there is one more use case for sdb: forwarding unix sockets onto > the workstation. > > > sdb does this? or you mean tcp sockets? > i've used ssh to fwd tcp sockets all around the place often enough - i've > never had to fwd a unix socket before. generally a unix socket is machine > dependent - eg its a comms channel but you may be talking about other > shared resources like shm segments, fd passing drm buffers around and you > make assumptions that when you talk on a unix socket you are on the same > arch - so endianess/alignment etc. are the same. so i generally would see a > fwd of unix sockets as "not commonly usefule due to the assumptions placed > on unix sockets". :) > Local sockets. At least chrome* uses it for remote debugging. * http://www.smartjava.org/content/remote-chrome-debugging-android<http://www.smartjava.org/content/remote-chrome-debugging-android> -- Adrian Marius Negreanu Intel Open Source Technology Center
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
