[haiku-development] Re: RFC: find_directory() API extension
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 4 Nov 2013 11:46:03 +0100 (CET)
> On November 4, 2013 at 8:20 AM Adrien Destugues <pulkomandy@xxxxxxxxx> wrote:
> I think using B_MAIN_IMAGE or B_CURRENT_IMAGE instead of &main, NULL, or
> &someRandomSymbol makes the API simpler, or at least, clearer.
>
> If we go for something like BResources, I think we need the complete set of
> SetTo* methodes there are in BResources.
Sounds like a good reason to keep the API as suggested :-)
> I'd say allowing MaliciousAddOn to access SecurePasswordStorageAddOn
> settings files just because they share the same host app is not a good idea,
> and better separation (by allowing the API to work only for the current
> add-on and the host application) allows for easier sandboxing of the
> add-ons. While the SetToImage call in BResources sounds just as dangerous,
> at least the packaged files are read-only, so it can't be used to inject
> something in other executables, now.
That makes really no sense at all. MaliciousAddOn runs in the same address
space, and can do anything it wants anyway.
Preventing add-ons to share paths via find_path() doesn't help at all.
If your application uses some kind of sandbox for the add-on (ie. a separate
process in a chroot environment), then them problem won't exist anyway, neither
the convenience to share stuff between add-ons.
Bye,
Axel.
Other related posts:
