> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Corentin > Lecouvey > Sent: Thursday, November 20, 2014 9:06 AM > To: [email protected] > Subject: Re: [Dev] transferring files from and to a service > > Hi Tomasz, > > Good to hear that security-manager has so much power. > > When receiving a file over bluetooth, it will be received in a "bluetooth" > user > folder as obexd will be run as "bluetooth". > The point then is to move the received file to the targeted user download > folder with the user ownership and permissions.
How do you identify the user on the head unit? The remote device sending - let's say a business card - need never be associated with the vehicle, nor have any user account there in? To add to the complication, GAP authentication is optional and perfectly legal use case. User confirmation is probably desirable, because I can see a very simple DoS attack flooding on your file system if it simply/automatically accepts and persists any type of files from random sources. Finally the formats, as defined int the BT spec are; Formats: 0x01 = vCard 2.1 0x02 = vCard 3.0 0x03 = vCal 1.0 0x04 = iCal 2.0 0x05 = vNote (as defined in [9]) 0x06 = vMessage (as defined in [9]) 0xFF = any type of object. Would all types be planted in the top level dir, or should a more logical structure [/contacts /calendar /Notes /Messages] be formulated? And I wonder for 0xFF - which could be anything from pdf, jpeg, mp3 - is some kind of mime control/management needed? Finally some infrastructure to determine whether your received file is what it claims to be would be beneficial too - i.e. someone renaming a pdf to vcard, or worse some nefarious content in the payload.... These are the interesting question that spring to mind perhaps worth considering? > We will need the security-manager help to do that. > > > > > +1. > > > > Security-Manager already has "power" to re-label files, so > chmod/chown/mv/DAC_OVERRIDE will not be any extension to its (already > high) capabilities. > > > > In the tandem <Security-Manager (SM), Bluetooth service (BT), The app > (APP)> probably Bluetooth would want to create file on its own to be able to > fill its contents quickly. Questions to be answered: > > > > 1) when the file needs to be shown to the application? > The file can be shown after the file has been transferred in the user > download folder. > > > 2) (follow-up) where should it be initially created: some BT-private > > directory where BT can fill its contents and then move+chmod+chown OR > > already the original destination (known & accessible to APP)) > I think the easiest way is the first proposal: receive the file in "bluetooth" > user provate directory and then move thanks to security-manager to the > right user directory. > > > 3) or, do we want to let SM expose API that manages files somehow and > then mv/chmod/chown it? If yes, this means using custom SM API in > Bluetooth for even bigger extent than just simple > move_and_chmod_and_chown() call. > I think if SM offers a move_and_chmod_and_chown() API, it could be > sufficient but I may wrong. > > Thanks and regards, > Corentin > > > > > > BRs, > > > > Tomasz > > > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > > > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
