[Dev] libcynara API
l.wojciechow at partner.samsung.com
Tue May 20 13:44:39 GMT 2014
All right lets sum up this thread. Please correct me if I misunderstood
1) There are two usages of cynara mentioned in thread: installation
process (setting up cynara policy rules) and privilege-checking. Lets
focus only on checking privileges (libcynara-client). Policy management
is done with another library and will be done by security-manager (Rafal
Krypa, Jan Olszak and I will publish details of security-manager design
2) synchronous API seems to be enough for now. [Zhang Xu, Patrick Ohly,
that is why we will focus only on synchronous API now. Design of
asynchronous API needs discussion about how to return the result when
its finally ready (callback, descriptor) - lets leave it for now, as no
one seems to need it for the moment.
3) parallel checks run from multi threads and cancellation of checks are
needed by some but not all usages to cynara check.[Patrick Ohly]. I
think we should provide thread-safe API that meets described
requirements described by Patrick (allowing cancellation and concurrent
Because there is a lot of to be done and there is always no time to do
it, we won't publish this API now, however it will be published in first
part of June - probably when first cynara-daemon based version of cynara
shall be released.
W dniu 2014-05-19 23:21, Patrick Ohly pisze:
> On Mon, 2014-05-19 at 19:45 +0000, Schaufler, Casey wrote:
>>> -----Original Message-----
>>> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
>>> Sent: Monday, May 19, 2014 12:26 PM
>>> To: Schaufler, Casey
>>> Cc: Lukasz Wojciechowski; dev at lists.tizen.org
>>> Subject: Re: [Dev] libcynara API
>>> On Mon, 2014-05-19 at 19:18 +0000, Schaufler, Casey wrote:
>>>>> I can't spawn a thread either to handle the call, because libcynara
>>>>> is not documented to be thread-safe. I don't want to make
>>>>> assumptions about what I may or may not do with threads.
>>>> You can count on libcynara being thread safe.
>>> What happens when one thread calls cynara_finish() while another is in
>> Do you plan to do that, or is this another hypothetical exercise?
> I plan to clean up properly when the process shuts down. This includes
> calling cynara_finish() ("should be called once before exiting
> service"). Once I do that after having introduced threading, I need to
> know what happens when there is a parallel cynara_check(), or whether I
> am expected to avoid this situation.
> So no, this is a very real exercise in figuring out how to use Cynara
>>> I can imagine multiple outcomes, some less pleasant than others.
>>> Whatever the outcome is, please document it.
>> Patrick, you are not going to get the level of documentation you
>> keep demanding. Read what's there. Look at the code.
> Okay, I did (commit f2559afa, May 8th). There are no mutex calls at the
> moment. cynara_finish() and cynara_check() are not thread-safe.
> cynara_check() just calls security_server_app_has_privilege(), which is
> going to change. So what does that tell me regarding thread-safety of
> the final Cynara?
> Nothing, therefore my questions.
> If I had relied on the code instead of asking, I would have come to the
> wrong conclusion that Cynara is not thread-safe.
> My point is, looking at code that is under development is pointless (no
> pun intended). There is an API proposal on the table how libcynara is
> meant to behave. The Cynara developers were so kind to invite comments
> early because they know that other developers will have to use this API.
> Now we have the chance to discuss the API while work on the
> implementation continues.
> That aside, even if the code was stable, are developers really supposed
> to look into the implementation to figure out how an API works? How can
> they be sure that they don't start to depend on behavior which isn't
> guaranteed to be present in the next release?
> In case it isn't obvious, I don't buy the "read the code" argument when
> it comes to APIs. An API is the binding contract between library
> implementer and library user. Using anything not documented there leads
> to the gray area of undefined behavior. The less we go there the better.
>> Ask specific
>> questions that are relevant to actual uses.
> I did that.
More information about the Dev