> -----Original Message----- > From: Jussi Laako [mailto:[email protected]] > Sent: Tuesday, October 15, 2013 1:45 AM > To: Schaufler, Casey > Cc: [email protected]; Le Foll, Dominique > Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID > issue > > On 14.10.2013 19:20, Schaufler, Casey wrote: > > 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. > > But this doesn't require root, just a capability attribute for the launcher > binary > itself to permit this just for the launcher? And the launcher can be fired up > as > part of the session and will gain the capability from the filesystem attribute > rather than through process inheritance?
Yes, this is also a viable approach. It requires a launcher for each user. The launchers are going to have to communicate with each other to coordinate (or so I'm told) seat placement and the like, but it is possible. I understand that a single launcher is greatly preferred. > I don't see this any different from having a privilege to set process > scheduling > class (usually required for audio), or accessing some privileged peripheral > like > GPS. > > > Teasers like this are unkind to the developers of the code. Please expound. > > It is commented in the server code, but the idea is simple: > 1) Receive request and check caller PID > 2) Read /proc/PID > 3) Verify that the peer still exists and has same PID > > This way you avoid the race condition that process would have terminated and > got replaced with another process. Step (3) verifies by send(), it has not > issued > close() or exit(), if it has the socket peer is disconnected (EPIPE). And > also that it > still has same pid using SO_PEERCRED, not iherited to another PID through > fork() and then exit(). Right, but this is only a problem if the system is not architected correctly. You don't want to do this! _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
