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?
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().
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
