/**

@page ac_page Access Control

The primary authorization mechanism of sysrepo operations relies on file access 
permissions set on the data files. Sysrepo automatically discovers user credentials
(UID and GID) of the process that is using the client library and permits the 
operation only if the user has sufficient permissions on manipulated data file.

To prevent privilege escalation and TOCTOU race conditions, sysrepo always 
changes its filesystem UID and GID (on Linux) or effective UID and GID (on Unixes) 
to the IDs of the process that is using the client library before accessing any data file. 

@section ifp Initial data file permissions
`sysrepoctl` tool (see @ref sysrepoctl) must be used for installing
of new YANG modules into sysrepo. By defualt,
`sysrepoctl` sets the access permissions on newly installed data files so that 
everyone can read and write into them. It is therfore strongly recommended to 
specify desired access permissions by `sysrepoctl --install` or 
`sysrepoctl --init` operations, or set them later using 
`sysrepoctl --change` operation.

@section user Starting sessions on behalf of a different user
Northbound access to sysrepo from management applications (such as NETCONF or 
RESTCONF server), may need sysrepo to authorize the operations not only
against the user under which the management application is running, but also 
against another user (e.g. user that is connected to the management application).
To support this requirement, sysrepo offers ::sr_session_start_user call that
can be used insead of ::sr_session_start. The ::sr_session_start_user call takes 
one additional argument - effective user name used to authorize the access to
the datastore in addition to automatically-detected real user name.

@note Be aware that authorization of specified user may fail with unexpected
errors in case that the client library uses its own Sysrepo Engine at the
moment and your process in not running under root privileges. To prevent
this situation, consider specifying SR_CONN_DAEMON_REQUIRED flag by
::sr_connect call.

@section subscriptions Authorization of sysrepo subscriptions
When a client subscribes for changes in the datastore, it automatically
creates a unix-domain socket aimed for delivery of notifications from Sysrepo Engine.
The socket is created in a YANG module-specific subdirectory of `SR_SUBSCRIPTIONS_SOCKET_DIR`.
To prevent delivery of malicious notifications, this subdirectory has the access
privileges derived from module's data file, so that only users authorized for
writing into the data module can deliver the notifications.

The proper permissions on module-specific subdirectory of `SR_SUBSCRIPTIONS_SOCKET_DIR`
are set by `sysrepoctl` tool by `--init`, `--install` and `--change` operations. Be aware that
if `SR_SUBSCRIPTIONS_SOCKET_DIR` is located on some temporary filesystem (e.g. `/tmp/`),
the subdirectories may get lost between restarts. In those cases, Sysrepo Engine 
is capable of creating the directories in runtime, but with some limitations:
correct file ownership will be derived from the data file only if the process
with Sysrepo Engine is authorized to execute the respective `chown` syscall
(otherwise the ownersip is derived from the ownership of the process
subscribing for notifications).

@section nacm NETCONF Access Control Model
NETCONF Access Control Model will be implemented later to allow northbound
management applications (such as NETCONF or RESTCONF server) to serve more
granular access control rules to remote management users than implicit sysrepo
rules per YANG-model (on data file level).

Of course, these rules will be more like "virtual", and really should be used only
for remote management authorization, since any local process will still be able
to manipulate the data file in any way regardless of the NACM rules configured for it,
given that it has sufficient permissions on data file level.

*/
