[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Schaufler, Casey casey.schaufler at intel.com
Mon Oct 14 16:20:28 GMT 2013

> -----Original Message-----
> From: Jussi Laako [mailto:jussi.laako at linux.intel.com]
> Sent: Monday, October 14, 2013 6:23 AM
> To: Schaufler, Casey
> Cc: dev at lists.tizen.org; Le Foll, Dominique
> Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID
> issue
> On 11.10.2013 19:30, Schaufler, Casey wrote:
> >
> > Dominique and I discussed the underlying problem in some detail and
> > believe that we have a cleaner solution.
> Nobody has yet explained why launcher needs to be somehow privileged and
> why it's not just a service part of a normal user session?

We are using Smack to provide application isolation. The launcher needs to set the Smack label of the application. Setting the Smack label of a process requires privilege. If there were no launcher involved (if the program were exec()ed) we could use the SMACK64EXEC behavior to achieve this. Since there is a launcher, and the launcher does not use exec() the launcher requires privilege.

> I'm not advocating for SO_PEERCRED & /proc/PID usage, but it can be made
> fairly proper. I have made a small demo client/server pair (attached) that
> should be quite OK for dealing with this combination for whatever use.
> I think I will also attempt to fix kernel regarding the "feature" I found (as
> commented in the sources).

Teasers like this are unkind to the developers of the code. Please expound.

> 	- Jussi

More information about the Dev mailing list