Release 1.9.18

* Change the way we pre-load symbol for syscall by calling it

Change-Id: Iee6cf0a127c50c5dfb9b44e88fad0f86857c1334

Change the way we pre-load symbol for syscall by calling it

Apparently using -1 as invalid argument can fail with SIGILL
on some configurations (happened on VD side).

Change-Id: I26d1d0411c637a67888a8d1e73892171004d05a3

Release 1.9.17

* Fix possible issue with lazy-symbol binding

Change-Id: I813fc8f6d1e61d01937664e09a1e8ee2546391ab

Fix possible issue with lazy-symbol binding

It seems possible that lazy binding of the SO symbols loaded by linker can cause problems
when the SIGSETXID arrives in some thread at the precise moment that a symbol in a thread
is being lazy-initialized. By doing calls below we're ensuring that symbols used inside
our handler are already loaded - lazy symbols (or any not-loaded) should not be called inside
a handler.

Also, changed the handler to be a regular function for easier debugging in kernel team.

Change-Id: I6a293374c38f47b18af86166d8b150af55469739

Release 1.9.16

* Add security_manager_is_app_from_pid() function

Change-Id: Iea0b4651a91b39cf4db20f82db2b722a4113d82a

Add security_manager_is_app_from_pid() function

Change-Id: I53ed6e507a945e1829e851621e521417bef831b5

Release 1.9.15

* Mark thread as dead in case of ESRCH
* Disable logging during thread sync
* Remove log from get_alive_threads()
* Put abort() in place to facilitate debugging

Change-Id: I7e56ad62b4338ddc0149bf322d155f939ecd478f

Mark thread as dead in case of ESRCH

This may speed up the thread sync a bit

Change-Id: Ib6a9c8f11a719615227efd24da18c65b91d69bf0

Disable logging during thread sync

Change-Id: I78e3154a6f5ae4697a461a0cbcce4affca2f50dd

Remove log from get_alive_threads()

No allocations allowed during thread sync

Change-Id: I3e539c4572ccfba96ba798383c1eea7d0260cd44

Put abort() in place to facilitate debugging

This way the backtrace will show us the point of failure

Change-Id: I97f70db007661b91baa757442b01c0cdc3270a5b

packaging: asan: skip Werror=stringop-overread

Change-Id: I10972a6d7bb01cc2d7e017b4d2a06189e33f674f
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

Release 1.9.14

* Change runtime Smack check in dev_wos cases to compile-time
* Add argument check to security_manager_set_identity()

Change-Id: I6ff748258a07d98c32d31f43c2b9e30a65f2dc9a

Change runtime Smack check in dev_wos cases to compile-time

Previous patch didn't work for PontusM smack-enabled environment.

Now this patch ensures that WITHOUT dev_wos flag, there is definitely
no difference in logic of security-manager, even in the absence of Smack
(ie. during image creation).

Change-Id: If37d9ceae8bcb5727e82f7310acff0358b820240

Add argument check to security_manager_set_identity()

Change-Id: Ibac8f33ae7eaef9bff7b67fdea53bc6f82591fbb

Release 1.9.13

* Change process_type elements with additional prefix

Change-Id: I5eb61bbc15a5aa8b8cc66ef046e2fb4f280d6605

Change process_type elements with additional prefix

askuser-notification couldn't be built because of ambiguity
in the APIs/enums.

Also, added missing header.

Change-Id: I1dbc4ef6cac4cdf74db200b85b790424d3b03ee4

Release 1.9.12

* Make security_manager_set_identity() and security_manager_self_is_app() work in dev_wos env
* Add function security_manager_set_identity()
* Add function security_manager_get_app_owner_uid()
* Silence SVACE warning
* Add function security_manager_self_is_app()
* Add security-manager permissive mode build option - dev_wos

Change-Id: I3c225668a16f500fd875a951534b4754e73bb4a2

Make security_manager_set_identity() and security_manager_self_is_app() work in dev_wos env

Change-Id: I42437b6db64b5beb20c06339ae8f782e15562bf4

Add function security_manager_set_identity()

Change-Id: Iec954c9a41cbf0547de685590685fdbf2b03e5d6

Add function security_manager_get_app_owner_uid()

Change-Id: Ie8281381b9c2ce509aec7ef3f5a0dbdcf7e58a1f

Silence SVACE warning

Change-Id: Ib9baacdbdd47f197b39c530a2b5bff75e0fc944e

Add function security_manager_self_is_app()

Change-Id: I03c4b947295359964578d1eb9c7e78ea2b9223ff

Add security-manager permissive mode build option - dev_wos

Usage: gbs <your favourite flags> --define "dev_wos 1".

If not explicitly specified, the option is disabled (switched to 0).

This option is intended only for development, not for release builds.

With this option, security-manager enters "permissive mode"
and doesn't operate on Smack or anything that may be related:
* at launching:
** doesn't change/modify/configure mount namespaces
** doesn't change/modify/configure capabilities
** doesn't change/modify/set Smack labels of app candidate threads
** does set group IDs based on privileges in the Cynara DB
* at app installation:
** doesn't change any Smack labels of files/folders

Other operations (ie. registering apps in the DB) should be performed
as usual.

rules-loader service is only checking the DB and making sure it has
all proper schema applied (DB versioning, etc.) but otherwise,
the one-shot service is not loading any Smack rules.

With this option, the application identification functions that rely
on Smack being the application identifier, that is:

security_manager_identify_app_from_socket
security_manager_identify_app_from_pid

...will return same string default_app_no_Smack_mode as the app pkg ID.

The API function:

security_manager_identify_app_from_cynara_client

...will normally parse Smack label, as its expected that cynara helpers
will be returning the string:

User::Pkg::default_app_no_Smack_mode

...as cynara client.

The API function:

security_manager_app_has_privilege

...will always return success & access granted.

This mode is intended to be used by for bring-up development
of Tizen working in container.

Change-Id: I24c15bb51f87faab3ac14b9dae5e296d682bd768

Release 1.9.11

* Remove remaining allocations
* Properly handle disappearing threads during sync

Change-Id: I9f45d44385d0a14805301707fe5e34602f571f35

Remove remaining allocations

Change-Id: Ibbfe3b014f32b40065db35081110806f5545d83f

Properly handle disappearing threads during sync

Plus few minor fixes

Change-Id: I0928f0ce811e26b25e3e3f566410f2ba95054416

Release 1.9.10

* Don't use allocations during signaling
* Initialize all resource_pid_t members
* Add negative test for generateProcessLabel

Change-Id: Iab1dbdf5dc17ba082c14db2fb65440221278673e

Don't use allocations during signaling

This is to prevent deadlock in malloc. It may happen if a supplementary
thread is interrupted after it took an internal glibc lock in malloc()
and it waits in a signal handler for the main thread. The main thread
won't be able to allocate memory due to lock taken by supplementary
thread.

Change-Id: I218075c2c2d6befa8fafb141e0507e64b5b47406

Initialize all resource_pid_t members

Change-Id: I819693bc3cf895c28204c07dc2ee66a50efa7aeb

Add negative test for generateProcessLabel

Change-Id: I8864eaae630302489d64b39013b433a267d3ed29

Release 1.9.9

* Remove unused code
* Fix double free in label monitor

Change-Id: I68dda88fefdee0b54f8791a153d63f7f1f98c1db

Remove unused code

Change-Id: Ib0423186dc3183ecedb519600922995d438bf2b8

Fix double free in label monitor

The pointer passed to initialize_inotify() is already managed by a unique_ptr.
In case of initialize_inotify() failure the pointer was being passed to
security_manager_app_labels_monitor_finish() where it was wrapped in a
unique_ptr again.

Add a helper non-throwing function operating on raw app_labels_monitor pointer
for properly closing it. Use it in security_manager_app_labels_monitor_finish()
and security_manager_app_labels_monitor_init().

Change-Id: I6f3b5883fde53ba3ded7764f3121f59ace053a10

Release 1.9.8

* Add check if HIGHEST priority is only for PREPARE_APP call
* Add check for CAP_MAC_ADMIN inside prepare_app2 call
* Added warning logs for events priority
* Fix logic in managing EAGAIN on sending signal in client (preapre_app2)
* Introduce separate thread for highest-priority events
* Make objects used in service_impl.cpp (mostly) thread safe
* Add highest priority & use it for SecurityModuleCall::PREPARE_APP
* Rename service-thread.h to service-thread-dispatcher.h
* Fix typo

Change-Id: Iea3507f1401b1b651ec2919626ddd1b863da9e44

Add check if HIGHEST priority is only for PREPARE_APP call

In case client was malicious, we could get events with highest
priority that are not PREPARE_APP calls, which could lead to
ie. multiple DB transactions being done in parallel threads
which the logic (service_impl.cpp) doesn't support as of now.

This technically eliminates the need for HIGHEST priority at all,
but it can be used in the future (if ie. a thread poll will be needed)
so it was not removed.

Change-Id: I30441b041610ef770cd0a23eb0d52216c7c1a7f3

Add check for CAP_MAC_ADMIN inside prepare_app2 call

Apparently in some weird scenarios, the wrt-loader or other launcher
that attempts at running apps, doesn't have the caps required.

Added check just prints proper error logs.

TODO: libsmack lacks function to get relabel-self list of labels
which probably should also be checked in the future (this is why
the check for CAP_MAC_ADMIN doesn't exit when there's no capability).

Change-Id: I5eeacb5ecb84883f6a4b2097887b82708297e98f

Added warning logs for events priority

This will ease debugging in case when many requests are being handled.

Change-Id: I85ee91d868c1e335e569fa67153a0871ce569eb9

Fix logic in managing EAGAIN on sending signal in client (prepare_app2)

Previous buggy version could lead to abort in case
2nd attempt at sending a signal went okay.

Change-Id: Ia0b0001f4ed602f9f7e5d40922998b5912a2414a

Introduce separate thread for highest-priority events

So far, only PREPARE_APP command on server side is treated as such.

Change-Id: Ia1dde64d0eaf0758f9f8c6c5e68d3e7a289eb3bb

Make objects used in service_impl.cpp (mostly) thread safe

So that its easier to introduce multiple-threads into the daemon.

**Disclaimer**
--------------
(1)
privilege_db is thread safe as long as only one thread is managing RW transactions
on the DB (each API of the DB takes & releases internal mutex).

This is enough to introduce a new separate thread just for prepare_app2 functionality
that only READS data and 2nd thread (current worker) operating on everything else,
including the RW operations.

To make a thread pool operate on many RW requests, transactions would need to be
handled in different way, so that they do not intertwine & the process
makes just one transaction at a time on the shared connection to the DB.

(2)
NSMountLogic is used only on policy update, so will be used only from the
standard worker thread (not the prepare_app2 thread). If thread pool will have
to be implemented in security-manager (or more than 1 thread to handle updates),
this would have to get reviewed.

(3)
Updates of permissible file with Smack labels of apps were left untouched to be done
on one thread (worker thread).

Change-Id: Idb228c52104058dce0c2ce43322613de09b8a06f

Add highest priority & use it for SecurityModuleCall::PREPARE_APP

So far without its separate thread, just to have separate queues
for the top-priority events.

Change-Id: I6d52e51fd8188a18f6b9650413ee6926139bdcd9

Rename service-thread.h to service-thread-dispatcher.h

This file will no longer implement only one service thread.
Changed the name not to be misleading.

Change-Id: Ibbf90daaf8a399108e5caabf4627ad8646156464

Fix typo

Change-Id: If73a6d618e446851689cbbe77e9ceee8a7fc292c

Release 1.9.7

* Add robot privileges

Change-Id: I9a9ee8878025e28485fa3cef4129f6c0c0737a16

Add robot privileges

http://tizen.org/privilege/robot.depthsensor
http://tizen.org/privilege/robot.map.get
http://tizen.org/privilege/robot.map.set
http://tizen.org/privilege/robot.movingpart
http://tizen.org/privilege/robot.navigation.get
http://tizen.org/privilege/robot.navigation.set
http://tizen.org/privilege/robot.property.read
http://tizen.org/privilege/robot.property.write
http://tizen.org/privilege/robot.speaker
http://tizen.org/privilege/robot.wheel

Change-Id: I525b92c01cc604f05f22c2ef6f942d891ebd16b9

Release: 1.9.6

* Revert "Fix tgkill retry logic"
* Set minimal cynara-admin version
* Optimization: batch cynara admin checks into one API call

Change-Id: I755213257aa8001b19bc67d106807349db06dc3f

Revert "Fix tgkill retry logic"

This reverts commit f4e8020905f10fbcb12a06060aab132d2e447f3f.

Apparently there are some failures/crashes in other modules only if the
reverted commit is used. Reverting temporarily. To be investigated
later.

Change-Id: I9bd9e6b7acff8868609e2a91823ac1e73f87ef22

Set minimal cynara-admin version

This is necessary as we started using the new cynara-admin API.

Change-Id: I4c660d22510326539c6e114fcbcf6d05307c558e

Optimization: batch cynara admin checks into one API call

Although the optimization's focus is on minimizing latency under load it shows some improvements overall.

Before (on emulator):
  additionalThreads 32 nConcurrentApps 1 samples 94
    prepareAppCandidate [us]:              min 145 max 755 avg 470 median 459 stddev 72
    prepareApp [us]:                       min 25 424 max 76 408 avg 40 300 median 42 693 stddev 7 330
    prepareAppCandidate + prepareApp [us]: min 25 868 max 76 857 avg 40 770 median 43 166 stddev 7 337
  nConcurrentApps 1 samples 135
    prepareAppCandidate [us]:              min 146 max 1 102 avg 476 median 457 stddev 88
    prepareApp [us]:                       min 13 769 max 26 616 avg 21 278 median 20 438 stddev 1 968
    prepareAppCandidate + prepareApp [us]: min 13 916 max 27 718 avg 21 754 median 20 893 stddev 1 993
  nConcurrentApps 2 samples 216
    prepareAppCandidate [us]:              min 317 max 1 285 avg 522 median 500 stddev 114
    prepareApp [us]:                       min 12 992 max 34 919 avg 24 143 median 23 894 stddev 4 035
    prepareAppCandidate + prepareApp [us]: min 13 598 max 35 250 avg 24 666 median 24 419 stddev 4 028
  nConcurrentApps 4 samples 384
    prepareAppCandidate [us]:              min 85 max 4 969 avg 678 median 600 stddev 552
    prepareApp [us]:                       min 12 682 max 49 079 avg 25 782 median 24 161 stddev 6 644
    prepareAppCandidate + prepareApp [us]: min 12 824 max 49 732 avg 26 461 median 24 774 stddev 6 609
  nConcurrentApps 8 samples 672
    prepareAppCandidate [us]:              min 77 max 4 609 avg 512 median 435 stddev 397
    prepareApp [us]:                       min 12 260 max 59 107 avg 25 890 median 24 256 stddev 7 760
    prepareAppCandidate + prepareApp [us]: min 12 378 max 59 575 avg 26 403 median 24 723 stddev 7 795
  nConcurrentApps 16 samples 1168
    prepareAppCandidate [us]:              min 79 max 4 619 avg 317 median 220 stddev 355
    prepareApp [us]:                       min 12 656 max 57 372 avg 26 940 median 26 660 stddev 7 674
    prepareAppCandidate + prepareApp [us]: min 12 806 max 57 963 avg 27 257 median 26 958 stddev 7 725
  nConcurrentApps 32 samples 1824
    prepareAppCandidate [us]:              min 76 max 4 945 avg 184 median 136 stddev 287
    prepareApp [us]:                       min 12 589 max 87 912 avg 37 803 median 36 480 stddev 15 334
    prepareAppCandidate + prepareApp [us]: min 12 757 max 88 015 avg 37 987 median 36 606 stddev 15 379

After (on emulator):
  additionalThreads 32 nConcurrentApps 1 samples 100
    prepareAppCandidate [us]:              min 197 max 655 avg 444 median 434 stddev 62
    prepareApp [us]:                       min 30 372 max 44 675 avg 38 708 median 41 516 stddev 4 686
    prepareAppCandidate + prepareApp [us]: min 30 795 max 45 328 avg 39 152 median 41 924 stddev 4 684
  nConcurrentApps 1 samples 165
    prepareAppCandidate [us]:              min 83 max 803 avg 221 median 132 stddev 159
    prepareApp [us]:                       min 12 224 max 23 058 avg 15 407 median 13 172 stddev 3 727
    prepareAppCandidate + prepareApp [us]: min 12 319 max 23 638 avg 15 628 median 13 294 stddev 3 879
  nConcurrentApps 2 samples 356
    prepareAppCandidate [us]:              min 66 max 1 470 avg 104 median 90 stddev 111
    prepareApp [us]:                       min 11 949 max 20 065 avg 13 307 median 13 160 stddev 912
    prepareAppCandidate + prepareApp [us]: min 12 025 max 20 144 avg 13 412 median 13 261 stddev 907
  nConcurrentApps 4 samples 552
    prepareAppCandidate [us]:              min 72 max 696 avg 110 median 94 stddev 58
    prepareApp [us]:                       min 12 115 max 18 504 avg 14 116 median 14 030 stddev 1 305
    prepareAppCandidate + prepareApp [us]: min 12 251 max 18 756 avg 14 226 median 14 128 stddev 1 316
  nConcurrentApps 8 samples 984
    prepareAppCandidate [us]:              min 71 max 2 196 avg 135 median 103 stddev 155
    prepareApp [us]:                       min 11 948 max 25 692 avg 16 838 median 16 695 stddev 2 939
    prepareAppCandidate + prepareApp [us]: min 12 041 max 26 019 avg 16 974 median 16 814 stddev 2 952
  nConcurrentApps 16 samples 1184
    prepareAppCandidate [us]:              min 75 max 5 523 avg 401 median 227 stddev 584
    prepareApp [us]:                       min 12 035 max 54 686 avg 25 184 median 24 884 stddev 7 269
    prepareAppCandidate + prepareApp [us]: min 12 175 max 56 117 avg 25 585 median 25 202 stddev 7 398
  nConcurrentApps 32 samples 1760
    prepareAppCandidate [us]:              min 72 max 4 791 avg 262 median 157 stddev 451
    prepareApp [us]:                       min 12 654 max 87 433 avg 35 770 median 34 678 stddev 14 002
    prepareAppCandidate + prepareApp [us]: min 12 777 max 88 638 avg 36 033 median 34 875 stddev 14 108

Change-Id: I0f039cf9c5023b78830816f776f108afdc8e2134

Release 1.9.5

* Change usleep time from 2 ms to 10 ms
* Add warning log for actually receiving a request from socket
* Fix potential memory leak

Change-Id: I4e43bf5ee16bf83214802b1fe3cc898758b584e7

Change usleep time from 2 ms to 10 ms

Apparently, the longer the sleep, less CPU time is used in heavy-load scenarios.

Change-Id: I79b89303eb14a74e699b7ba2e2980dd499dcb781

Add warning log for actually receiving a request from socket

Needed by VD to investigate few issues with performance on slower boards.

Change-Id: I3d0ba83303b4897212afe1dd100eef26a160f27a

Fix potential memory leak

Change-Id: I6a14537d3e510046b37603aa99e75f8f96b3a845

Release 1.9.4

* Add core privilege: isu.admin
* Add unit tests for increased coverage
* Fix tgkill retry logic

Change-Id: I5a1d33a07134d9d747912b0c26c9c5ffd08a4313

Add core privilege: isu.admin

Change-Id: I71d23fe21f9b82226d5604e5a173608068715c19

Add unit tests for increased coverage

Change-Id: Ifbb5ad446b4aa4c2d350f630ea713cd2d7bbbb9d

Fix tgkill retry logic

If second tgkill attempt after EAGAIN succeeds, the abort() would still
be called. This commit fixes it.

Change-Id: I507c32188924fbb38f521c5d7fd1c1897c7ce534

Release 1.9.3

* Add more warning logs for performance analysis on release builds
* Remove pkg existance check in labelPaths function
* Remove unused function

Change-Id: If9efe93e4ffb4e2019724c258632ff6d60086dba

Add more warning logs for performance analysis on release builds

Change-Id: Ie83e2768d4da2208e1e4666b2c1969b2c38e2a6a

Remove pkg existance check in labelPaths function

The function is called 2 out of 3 times in places
where the package was already added (appInstall, appUpdate),
so no check is needed.

Added the check manually before function call in registering paths API,
where in fact we need to return invalid param for backward compatibility.

Change-Id: I7fb8b967409972ef1f0734f40320682b6bf6cc1b

Remove unused function

Change-Id: I07191ea6a8a7632c7f0446fe5724eea678dae0f2

Release 1.9.2

* Add core privilege: keymanager.extended

Change-Id: Ib758362fe042a0d25f599a70304be926c8637897

Add core privilege: keymanager.extended

- keymanager.extended (platform level): app can use extended CKMC API

Change-Id: I1eee03db7511a7bbf18daf5dcc979857f258a4cf

Release 1.9.1

* Add mitigation for DDOS attack
* Adjust coverage script after lcov upgrade

Change-Id: Ib852206bcbeb276db97152c7b463916f62eff483

Add mitigation for DDOS attack

Adversary can send too big message to the daemon,
making it fail on allocation. Few places were required
to be enhanced with catch for std::bad_alloc & proper
graceful closing of connection instead of terminating
the process.

Change-Id: Id05dd3ee3d323a8d47ba93e33fae9d9bc6bb255d

Adjust coverage script after lcov upgrade

Change-Id: I5e02bfd884ea1fa8b6f96796bcaea143ac6eb10c

Release 1.9.0

* Add core privilege: wifi.secureinfo

Change-Id: I33704a6c60d798d788fd89dcfef7fe9c33a94871

Add core privilege: wifi.secureinfo

- wifi.secureinfo (platform level): app can read Wi-Fi security information

Change-Id: Iad23ef25c8c2aa65ecf27e47cc1ebbf59c645292

Release 1.8.14

* Removed unnecessary bloat & fix readme
* Modified error log in case of failed relabel_self setup
* Add unit tests for permissible file update, initialization and removal
* Implement a mechanism for permissible file repair
* Implement permissible file integrity verification

Change-Id: I1155d61b5343f8981facd2a3fb5b5a9d7f71a144

Removed unnecessary bloat & fix readme

Change-Id: Iafa766759f035a2b9f5d4232d0b16eac46781f4e

Modified error log in case of failed relabel_self setup

Error in this place sometimes happens on VD images, but without
harsh consequences, as if it happened in places where the label
list is still empty. Added number of labels to be printed.

Change-Id: I564b819dd53ae359b908ee111573cdde950343ce

Add unit tests for permissible file update, initialization and removal

Change-Id: Id05b5deaa8d4fd39c53478c555524f4be4ddac2b

Implement a mechanism for permissible file repair

Permissible files that have been marked as invalid due to their hash
not matching can now be repaired by fetching the relevant data directly
form PrivilegeDb. This works for both the service and the client library.
As the client lacks the privileges to do it on their own, in that case
a request is sent to the Security Manager daemon.

Change-Id: I43fee3d39c015a7fbba0e674c29c904ac26e91bf

Implement permissible file integrity verification

Permissible files have a SHA-1 hash attached at the beginning.
Upon opening it is compared with a new hash calculated from the
file content in order to verify if the file's integrity is intact.
An error is thrown should the hashes differ. Files with no hash are
still supported but reading/updating the rules stored in them
will cause them to automatically switch to the new system.

Change-Id: I5ec379b58cc78e63bcde084ada43273237d61beb

Release 1.8.13

* Rework security_manager_sync_threads_internal()

Change-Id: I03550d31dd5d8b1230dddc0f8c0b04e022beafce

Rework security_manager_sync_threads_internal()

Add "stop-the-world" implemenation in signal handler.

Why this change may be needed?
------------------------------

On slower platforms, some dotnet-based app candidate processes
tend to have 10-15-... threads. Sending signals that change
Smack labels & drop caps to each of them can be delayed - for apps
that don't have a priority to get launched, this can take up
to 10-15 seconds, in pathological cases (observed in real life,
on low-end boards). In such situation, there's non-zero time window
when some threads have changed security attributes and some
haven't  - access control issues occur in app candidate's logic,
leading to serious errors & abort()s in the launched app.

With this modification, threads change the Smack labels & capabilities
when none of them are performing any of their original app candidate
logic and the only thread NOT in signal handler is the one
with security-manager client library.

This is expected to limit Smack/permission issues mentioned earlier.

Details, disclaimers:
---------------------

This implementation CANNOT fix an issue where app candidate process
created a resource (ie. a file) BEFORE call to security_manager_prepare_app()
and then, wants to access it (for read) AFTER call to the function.
This is because, before the transition, the process has either User
or System::Privileged Smack label, to which apps do not have R Smack rule
(such issues can still occur and can't be dealt with at security-manger level).

This implementation can be up to 3x slower on low-end boards,
as we have 3 waiting points here, instead of one:
    1) waiting for signals to arrive in all threads (place from old implementation)
    2) waiting for signals to be able to start changing caps/Smack labels
    3) waiting for signals to sync after attributes are changed to start work

Tests performed on Tizen emulator show about 30-40% slowdown
of prepare app vs. previous implementation.

This implementation assumes that the size of set of all TIDs
that can appear in a process (already dead + currently alive) will not exceed 1000.
A global array of std::atomic's is used to keep track of each thread's
state in the execution of signal handler.

This implementation uses sleep() and std::atomic to implement
waiting for the barrier inside a signal handler (home-made spinlock,
basically). While this can be done more elegantly, ie. with std::atomic's wait()
functionality, this C++ feature doesn't seem to be supported in current Tizen
toolchain (c++2a supported, not full c++20).

An alternative way for synchronization would be to use high-profile system
resources like fd's or semaphores, however, because the VD H/W platform
where the issue of thread dis-synchronization happens is very slow, interfacing
with kernel was limited to minimum, as adding any context switch to kernel
may slow down even more.

Change-Id: Ic7037acaeb4e3eaab03284ae63216e7ab4d6d862

Release 1.8.12

* Add even more logs around IPC

Change-Id: I15012a4e14844397b3115ff8f21a6fb57256d524

Add even more logs around IPC

Needed by VD division for diagnostic purposes on release images.

Change-Id: Id45f577c50234a80152d646b6dc11f12b6633690

Release 1.8.11

* Add better logs around IPC

Change-Id: Ib5aa13e91250469b64c301ebfc17e7f5e7f2b2d1

Add better logs around IPC

Needed by VD division to debug socket clogging problem in the kernel.

Change-Id: Ic1764b8e9342f93911dcf26f6c03fca028a7f72f

Release 1.8.10

* Add mitigation for long processing of signals in VD's environments

Change-Id: I499a9b16bd2ba9552ac8972c7efba8e26b1906b2

Add mitigation for long processing of signals in VD's environments

* waiting for signals - timeout increased to 20s from 10s
* added 2 ms timeout if tgkill() will return EAGAIN (happend in actual product image in testing once)

Change-Id: I26ce63e66fc36536136a3eab7903efb07fb35437

Release 1.8.9

* Create DB file backup in case it was discovered to be corrupted
* Fix app-defined privileges certificate verification
* Migrate to openssl3

Change-Id: I5ebe3bbf8e081d0fbb2efe9f3ae2813db2cb158f

Create DB file backup in case it was discovered to be corrupted

This way, the DB can be later analyzed in detail.
Unit tests were modified to check if the backup
is properly created.

This change was requested by VD division.

Change-Id: I151113f793a2d87ea5060931ffeef72f511558cf

Fix app-defined privileges certificate verification

Since OpenSSL 3.0 a number of additional checks introduced to X509_verify_cert()
according to requirements in RFC 5280 in case X509_V_FLAG_X509_STRICT is set.
For example, the basicConstraints of CA certificates must be marked critical.

This checks cause verification failure for not well-formed certificates.
Having backward compatibility in mind, it's better to disable strict checking
than replacing all broken certificates in applications.

Change-Id: I8c6cb50be7c36ff7ef3d5c221dd4f066c2626be6

Migrate to openssl3

Change-Id: Ibab2eed97c6011e303433e48322b3f00fbb48a62

Release 1.8.8

* Fix error checking for open

Change-Id: I8780a3601482f84681f37009aa7dd0fd6ad7f4c8

Fix error checking for open

stdin should not get closed, but anyway, this should get fixed.

Change-Id: Icfeb0e8be0893ec14640f579d7818670d84ef918

Release 1.8.7

* Improve threads' privilege synchronisation

Change-Id: I178bee9a70016bf29ac62de67576b3580ecbdf9b

Improve threads' privilege synchronisation

* Drop the caps after the threads have been listed for a second time
  (after the sync). This is to avoid errors during accessing /proc for
  newly spawned threads as a unprivileged process.
* Check if newly spawned threads have correct labels.
* Retry the privileges sync twice for all remaining privileged threads.
* Retry listing of /proc/self/task/ in case of failure.
* Use set instead of vector for easier tid checks.
* Omit main thread from the list.

Change-Id: I21e7e5dd3d5efb70fe51a1597bd7bc4ccf1099e8

Release 1.8.6

* Revert "Change the signal used by security-manager prepare_app implementation"

Change-Id: I26f7f7e384a4b0ca127acad3399d94e2c3a3fce1

Revert "Change the signal used by security-manager prepare_app implementation"

This reverts commit 4e26238c9e62a442042145a42207c8b669bf939d.

TCT tests seem to fail when signal is changed to SIGRTMIN+2
from SIGSETXID used previously.

Change-Id: Ib7df235addc30d6fb4b5d503a6f43d012218b55d

Release 1.8.5

* Increase waiting time for threads to receive signal
* Change the signal used by security-manager prepare_app implementation
* Fix an ugly bug in printing debug information about threads

Change-Id: I29507a05612dab8fcff9629bd743885b02c19ad5

Increase waiting time for threads to receive signal

As discussed with VD engineers, thats now increased to 10 seconds.
Also, additional log with information about waiting (warning log)
was added.

Change-Id: Iaf76777af2adb2ce65f98a71349a99e1a0704cd5

Change the signal used by security-manager prepare_app implementation

SIGSETXID was used previously to mimic the exact behaviour of glibc.

However, in testing on VD side using SIGSETXID can cause interference
with regular glibc usage, which also leads to abort().

To give more details: if threads are so delayed that their signal handling
is done ie. > 2 seconds after the sending was done, the signal arrives
in the thread when security-manager already did change the signal handler
back to original glibc. Then, glibc, checks whether it sent the signal,
it recognizes it didn't, and aborts/quits.

Changing signal number will not cause glibc to abort/fail, and if execution
gets back to security-manager main thread, IT will fail, printing
all necessary information about threads for debugging, before calling abort().

Changed signal number to SIGRTMIN+2, as advised.

Change-Id: I9b755504898daee71997ee35023c3d647e332b84

Fix an ugly bug in printing debug information about threads

The for range was calcualted based on wrong variable,
resulting in not all threads information being printed.

Also, changed error handling a bit.

Change-Id: I45fb88c889fb158ba63e0eb55f8d9c813fb40f9c

Release 1.8.4

* Fix static analysis issues
* Fix build for new toolchain
* Add additional debug information in prepare_app

Change-Id: I5ff8f36c31f7e5527a816842433a56c1ec2d1a00

Fix static analysis issues

Change-Id: I90839d874efd4e8b53a7c30870182fbf83c8c248

Fix build for new toolchain

Change-Id: I156cf22c4a752057490a6d6d7fbe040358fc933d