On 6/14/2021 8:32 AM, Kees Cook wrote: > On Mon, Jun 14, 2021 at 06:02:34PM +0800, youling257 wrote: >> I used mainline kernel on android, this patch cause "failed to retrieve pid context" problem. >> >> 06-14 02:15:51.165 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1682) failed to retrieve pid context. >> 06-14 02:15:51.166 1685 1685 E ServiceManager: add_service('batteryproperties',1) uid=0 - PERMISSION DENIED >> 06-14 02:15:51.166 1682 1682 I ServiceManager: addService() batteryproperties failed (err -1 - no service manager yet?). Retrying... >> 06-14 02:15:51.197 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1695) failed to retrieve pid context. >> 06-14 02:15:51.197 1685 1685 E ServiceManager: add_service('android.security.keystore',1) uid=1017 - PERMISSION DENIED >> 06-14 02:15:51.198 1695 1695 I ServiceManager: addService() android.security.keystore failed (err -1 - no service manager yet?). Retrying... >> 06-14 02:15:51.207 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1708) failed to retrieve pid context. >> 06-14 02:15:51.207 1685 1685 E ServiceManager: add_service('android.service.gatekeeper.IGateKeeperService',1) uid=1000 - PERMISSION DENIED >> 06-14 02:15:51.207 1708 1708 I ServiceManager: addService() android.service.gatekeeper.IGateKeeperService failed (err -1 - no service manager yet?). Retrying... >> 06-14 02:15:51.275 1685 1685 E ServiceManager: SELinux: getpidcon(pid=1693) failed to retrieve pid context. >> 06-14 02:15:51.275 1692 1692 I cameraserver: ServiceManager: 0xf6d309e0 >> 06-14 02:15:51.275 1685 1685 E ServiceManager: add_service('drm.drmManager',1) uid=1019 - PERMISSION DENIED >> 06-14 02:15:51.276 1693 1693 I ServiceManager: addService() drm.drmManager failed (err -1 - no service manager yet?). Retrying... >> > Argh. Are you able to uncover what userspace is doing here? > > So far, my test cases are: > > 1) self: open, write, close: allowed > 2) self: open, clone thread. thread: change privileges, write, close: allowed > 3) self: open, give to privileged process. privileged process: write: reject I found an issue under Smack where a privileged process opened /proc/self/attr/smack/current, wrote to it successfully, then tried to write to it again, which failed because the cred has changed. That's not a common use case. The usual case is open, write, close. If ServiceManager is assuming that it can leave a descriptor open while manipulations are in progress it could encounter the same kind of problem.