<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A" xml:lang="en"><title>Description</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Server applications have been introduced to Symbian platform since v9.0
for <xref href="GUID-4BFEDD79-9502-526A-BA7B-97550A6F0601.dita">Platform Security</xref>.
Principally, they offer a more secure solution to embedded applications. </p>
<p>A server application is an application that contains a server to which
other applications can connect. Importantly, the server application runs in
a separate <xref href="GUID-E6F08B67-8DBC-5896-946D-BD0D27F82FE2.dita#GUID-E6F08B67-8DBC-5896-946D-BD0D27F82FE2/GUID-AC0E13F3-5DFE-5060-BE09-B76A08632B5E">process</xref> than
that of the client (e.g. another application) that launched it. This lets
each party protect their own memory and storage/disk space and have flexible
security policies (which is in contrast to interactions between DLL-based
applications that allow complete access to the memory and disk space of their
hosts). The server application system permits applications to establish powerful
inter-process communications links. This allows applications and other UI
components to observe the principle of least privilege by only requiring <xref href="GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A.dita#GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A/GUID-049F04BC-546E-53F9-8212-C0DC6D5B94C2">capabilities</xref> necessary
to do their job, and not the capabilities of applications that use them or
of components that are used by them. It also allows for better compartmentalisation
of data, by restricting access to <xref href="GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A.dita#GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A/GUID-8CACFFD5-51FF-5902-B4B5-2DBA506A3CD9">data
caged files</xref> to a client/sever interface. Correct use of the server
application system can improve the security, stability, robustness, usability
and functionality of a platform. </p>
<p>A client can launch one or many server applications; server applications
can have multiple clients, though they have a one-to-one relationship when
they're running. </p>
<section id="GUID-A3712A05-A6A1-549F-98E6-5E9DEC37006C"><title>Services</title> <p>Clients
and server applications interact through common services, which adhere to
a protocol defining the communication channel between the two. This inter-process
communication channel also provides a security checkpoint for application
capability checking, etc.. </p> <p>Services offer useful functionality to
clients, for example, applications often use other applications to send messages,
view, edit and create files, these can be considered services, which may be
implemented in a number of ways (e.g. a printing service). The client asks
the server (via the application containing it) to perform such tasks. </p> <p>Server
applications and clients can each have one or many services. Each service
type is identified by a UID, see the <xref href="GUID-F7CC81CE-E823-5196-944A-5F7524411A08.dita">Registration
and discovery</xref> section below. </p> </section>
<section id="GUID-049F04BC-546E-53F9-8212-C0DC6D5B94C2"><title>Capabilities</title> <p>The
Symbian <xref href="GUID-4BFEDD79-9502-526A-BA7B-97550A6F0601.dita">Platform Security</xref> system
uses capabilities to police who is allowed to do what in the system. </p> <p>Processes
are assigned capabilities in their executables at build time. These capabilities
indicate the things that the process is allowed to do, for example, <codeph>ReadUserData</codeph> (see <codeph>TCapability::ECapabilityReadUserData</codeph>). </p> <p>Servers can check that their clients have particular capabilities
before they carry out client requests. For example, a contacts server may
check that a client process has the <codeph>ReadUserData</codeph> capability. </p> <p>DLLs
may also be assigned capabilities. This means that the DLL is trusted to be
used in a process which has these capabilities. You cannot load a DLL into
a process when the process has capabilities that the DLL does not have. DLLs
cannot add capabilities to processes, a DLL having a capability does not mean
that the DLL can use that capability. The capabilities that a DLL can use
depend on the process that it is executing in. </p> <p>Before the introduction
of platform security, application and other UI component interaction was achieved
with the following techniques. Embedding allowed one application to use another
inside its process. View switching allowed one application to control which
views are displayed by another. DLLs allowed static functionality to be added
to an application. Plug-in DLLs allowed dynamic addition of functionality
to an application. </p> <p>These techniques are all still available, to some
extent, in the application frameworks with platform security. However, those
that rely on DLLs for UI component interaction are now limited, by the capability
rules described above. To achieve fully flexible relationships between UI
components a client/server or other cross process link between components
is now required. </p> <p>For example, consider a server that allows clients
to send an SMS message. Clearly this will require its clients to have a network
capability. However, it is reasonable for a platform to want the user to decide
when SMS messages are sent, no matter which application (with or without capabilities)
wants to send them. Therefore, the platform will want to supply a UI component
that has the ability to send SMS messages on behalf of other applications,
asking the user for confirmation. If such a component were supplied as a DLL,
it would have to run in the client applications process and run with the capabilities
of that process. This may prevent it from being able to send SMS messages
if the client application does not already have that capability. If, however,
the component is supplied as a separate application running in its own process
with a client/server interface allowing other applications to use it, then
it can always ask the user and always send messages, no matter which application
originates the request. Note that such cases where the user is allowed to
permit actions without capabilities are only valid for "user capabilities". </p> </section>
<section id="GUID-8CACFFD5-51FF-5902-B4B5-2DBA506A3CD9"><title>Data caging</title> <p>The
Symbian <xref href="GUID-4BFEDD79-9502-526A-BA7B-97550A6F0601.dita">Platform Security</xref> system
allows processes to have private files, which are only accessible by that
process. Any code that is executing within a process, including code loaded
in DLLs, can access the files in the process's data cage. Code that is executing
in other processes cannot access the files in the data cage, except where
the owning process explicitly supports it. A process can allow other processes
access to individual files in its data cage by file handle sharing, or by
providing an API which encapsulates access to data caged files. Such access
to data caged files and data must be granted with care according to the sensitivity
of the data. </p> <p>Consider a memo-pad application that stores a user's
memos as files in its data cage. This application wants to be able to send
memos in messages, so it links to a "send-as" library. If this send-as library
loads the message transports as DLLs in the memo-pad application's process,
an evil message transport DLL could access all the memo files, deleting, copying
or altering them. If however the send-as library uses IPC connections to the
message transports, the memo pad application controls exactly how much these
message transports can access, limiting the amount of damage that an evil
message transport can do. Similarly, the memo-pad application may offer an
API to allow other processes to access the memos. Since the memos are considered
to be user data, the access should be limited to processes with <codeph>ReadUserData</codeph> capability. </p> </section>
<section><title>See also</title><ul>
<li><p><xref href="GUID-940F3F6E-BA9C-5E19-9AC5-D848B5E175FB.dita">Application
Architecture Overview</xref></p></li>
</ul></section>
</conbody></concept>