UID not permitted to start service in init.rc unless added to white list in property_service.c

[Ulrik Bech Hald]

We're trying to setup Android to use PPP over a GPRS connection on the
Omapzoom platform and have run into a question regarding UID
permissions to startup a service in init.rc.

To enable ppp the following property is set in init.rc:

setprop ro.radio.use-ppp yes

After doing this, the Java Telephony framework expects a service named
"pppd_gprs" to be available to be started. This service is the ppp
daemon, setting up the ppp link. So, we added the service in init.rc:

service pppd_gprs /etc/init.gprs-pppd
user root
group radio cache inet misc
disabled

Sidenote: the init.gprs-pppd script eventually starts up the ppp
daemon, but is used as a wrapper to capture the exit status of the
pppd.

However, now that the service is defined, the java telephony stack
complains that the user radio (uid 1001) is not permitted to start the
pppd_gprs service:

<3>init: sys_prop: Unable to start service ctl [pppd_gprs] uid: 1001
pid:821
init: sys_prop: Unable to start service ctl [pppd_gprs] uid: 1001
pid:821

Since the telephony stack has to be uid 1001, permissions has to be
added. After some code-crawling we found a working hack to this
problem. In order to allow the Radio user to start pppd we could add
an entry to the control_perms “whitelist” in /system/core/init/
property_service.c.

Like this:

/*
* White list of UID that are allowed to start/stop services.
* Currently there are no user apps that require.
*/
struct {
const char *service;
unsigned int uid;
} control_perms[] = {
{"pppd_gprs", AID_RADIO },
{NULL, 0 }
};

So, here's the question:
Is hardcoding like this really the only way of giving permissions for
a non-root user to start a service ? If so, that seems very
inflexible.

[Nick Pelly]

Another option is to have the system server start pppd on behalf of
the app. You could use a simple aidl interface between the app and the
system server.

Nick
Android Systems Engineer