> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Carsten > Haitzler > Sent: Monday, April 14, 2014 4:47 PM > To: Lukasz Wojciechowski > Cc: [email protected] > Subject: Re: [Dev] Cynara > > On Tue, 08 Apr 2014 20:57:37 +0200 Lukasz Wojciechowski > <[email protected]> said: > > > Services that are being used by applications need to control if the > > caller has sufficient privileges to call each API. In Tizen 2.2.X this > > level of access control was done using very detailed Smack policy on IPC > > mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack > > policy, there is a need for user-space mechanism that complements the > > solution. This is a place for new module - Cynara. > > > > Details can be found at wiki page: > > http://wiki.tizen.org/wiki/Security:Cynara > > > > Page is still being constructed, but is is high time to share and > > probably start a discussion. > > I will be glad to answer any questions about it. > > I plan to publish roadmap for Cynara development and API draft this week. > > cynara_check ... where will the service daemon get the client string, and > client_session string?
SO_PEERCRED and SO_PEERSEC. Dependable. The wiki includes examples of how to do it. > if these are provided by the client... a client can just lie. You're correct. > why not just provide the PID of the client directly to cynara and it does > the rest? (this also means you can change, in future, what parameters/info > you > use to categorize a client). This is one of the methods available. There are race conditions in /proc, so it isn't technically reliable. > > -- > Carsten Haitzler (The Rasterman) <[email protected]> > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
