Skip to content

Conversation

@ehem
Copy link

@ehem ehem commented Aug 6, 2016

The 64-bit may or may not be a big deal. I'm actually pretty worried some 64-bit devices may never run app_process32 in privileged mode, at which point the hook to start the su daemon fails. The 64-bit builds expect to chain to app_process64 instead.

Elliott Mitchell added 3 commits August 5, 2016 13:21
Check for fork() failing (can happen).  Merge the two execve() points for
the original app_process32 together.  Make the daemon call an execve().

Move the declaration of setup_policy() to a header.  Avoids problems if
it gets changed somewhere.

Adjust the use of types in policy.c, while hashtab_key_t is a char *, the
compiler emits warnings if you're not calling it that.  Also add const to
these since the value IS constant.
A device where the system APKs were located in /system/<name>/<name>.apk
instead of /system/<name>.apk has been observed.  Other devices may be
following this in the future so be prepared.
This builds 64-bit versions of the binaries.  The 64-bit versions expect
to chain to app_process64.  This adds another hook into the system making
us less likely to get expelled.  I suspect on 64-bit systems
app_process32 may never get called in a privledged context.

The update script needs to be modified to add in the extra hook.
@lbdroid
Copy link

lbdroid commented Aug 26, 2016

Use of app_process to hook in is obsolete and not recommended. As long as the device is capable of executing a 32bit binary from an init script, there should be no advantage to 64bit builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants