So, assuming that the APKs in /system/app have had their classes.dex extracted and optimized to separate .odex files, it sounds like removing world read permission from the .odex files would prevent the code being extracted from a live device (bearing in mind the separate, and very valid, point made by William Enck above), and would not create a problem for the framework. Is that right?
On Aug 25, 1:14 am, Dianne Hackborn <[email protected]> wrote: > A forward locked app has its resources copied out into another file that is > made public (so it can take significantly more space in flash that a > non-forward locked app). > > > > On Mon, Aug 24, 2009 at 2:22 PM, Scytmo <[email protected]> wrote: > > > Thanks for the response, Dianne, but that doesn't tally with my > > observation about ownership and permissions for 'forward lock' > > applications. These appear to be stored in /data/app-private, > > uid=system, gid=app_XX (that is, whatever uid/gid the app has been > > assigned) with mode=0640 (that is, read-write for uid=system, read- > > only for gid=app_XX, and no access for world). > > > Is my observation about 'forward lock' applications incorrect? Or are > > there some caveats to applications needing to be world readable? > > > Thanks. > > > On Aug 24, 8:10 pm, Dianne Hackborn <[email protected]> wrote: > > > Sorry, there isn't any way to do this. Applications need to be world > > > readable so that other applications can access their resources -- for > > > example for a home app to display its icon and label, for intent > > resolvers > > > to display icon and label, for an app widget host to inflate the widget > > from > > > its resources, for a status bar to display its icon and inflated details > > > layout, etc. > > > > On Mon, Aug 24, 2009 at 2:04 AM, Scytmo <[email protected]> wrote: > > > > > Hi, > > > > > Is there any way for an OEM to give the same level of protection to > > > > packages loaded into /system/app as is given to 'forward locked' > > > > downloaded packages (which are placed in /data/app-private without > > > > world read permission)? > > > > > I understand that the packages in /system/app should have had dexopt > > > > run, so the APKs do not contain classes.dex, and there is a > > > > separate .odex file alongside. However, for a package that does not > > > > require any 'signature' or 'signatureOrSystem' permissions, it seems > > > > possible to extract the APK and odex, and create a new self-signed > > > > package. This would appear to need an 'undexopt' step, to get > > > > classes.dex back from the .odex file - and, while I can't see any > > > > tools available that would do this at the moment, it doesn't seem > > > > intractible. > > > > > Is there any particular reason why the files in /system/app are world- > > > > readable? Could a permission scheme like that used in /data/app- > > > > private be used, uid=system, gid=app_XX, mode=0640? I guess one issue > > > > would be determining the correct gid. Any other issues with doing > > > > this? > > > > > Scytmo > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > > provide private support, and so won't reply to such e-mails. All such > > > questions should be posted on public forums, where I and others can see > > and > > > answer them. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them.
