[Dev] libcynara API

Lukasz Wojciechowski 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 
something.

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 
soon).

2) synchronous API seems to be enough for now. [Zhang Xu, Patrick Ohly, 
Rees Kevron].
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 
checks launching).
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.

Best wishes
Lukasz




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
>>> cynara_check()?
>> 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
> correctly.
>
>>> 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 mailing list