ViewVC logotype

Contents of /trunk/grid-mw-security/ees/thesis/eef.tex

Parent Directory Parent Directory | Revision Log Revision Log

Revision 953 - (show annotations) (download) (as text)
Wed Oct 21 08:40:48 2009 UTC (12 years, 3 months ago) by aramv
File MIME type: text/x-latex
File size: 6200 byte(s)
One to beam up
1 \chapter{Implementation of EEF components}
3 \section{Programming philosophy}
4 Since C, as a procedural language, lacks object-oriented concepts I have adopted the oft-used trick of using structures with function pointers as rudimentary objects.
5 This proved to be a very natural way to use C for large projects.
6 % kan uit requirements
7 % welke platformen reeds getest
9 I have tried to adhere to Unix-philosophy when creating the EEF.
10 The configure script allows enabling debug output and specifying a modules path, where plug-ins should be loaded from.
12 \section{Evaluation Manager}
13 This component is directly descended from LCMAPS, because it was possible to reuse the parser thanks to its loose coupling.
14 I have implemented the callback functions needed by the parser from scratch because the EEF is structured differently than LCMAPS.
15 However, I have reused the data structures for describing policies from LCMAPS.
17 \subsection{Implementation challenges}
18 The Lex and Yacc code is interpreted to create pure C.
19 These output files will eventually be shipped with the software source package.
20 Because differing Lex implementations and versions provide different functionality to clean up used memory after parsing, the Lex version used is established by the configure script using M4 macros.
21 This information is then used to define a constant, upon which conditional compilation of the cleanup function of the Evaluation Manager can occur.
23 I've found the parser code inherited from LCMAPS to be really difficult to read.
24 This made implementing new callbacks quite difficult.
25 Unfortunately it is necessary to read and understand the parser code before it can be simplified or rewritten, which would likely be very time-consuming.
26 After spending some time analyzing what each callback does by trial and error, I understood it well enough to integrate its functionality into the EEF.
27 % WHY?!
28 % vertel dat alles behalve de parser nieuw is, ipv andersom
30 \section{Plug-in Manager}
31 This component is possibly the most intricate, as it requires linking to code at run-time.
32 ANSI C has a set of functions that allow run-time linking of shared objects: the \textit{dl} functions.
33 This is also how the Linux kernel works with dynamically loaded modules.
35 \subsection{Unforeseen shortcomings}
36 The path to load plug-in modules from can be set by a command-line argument to the configure script, but might be overridden by a directive in the configuration file.
37 This didn't occur to me until after I had a working parser that executed plug-ins.
38 I had to make some changes that ensure plug-ins will only get loaded after the configuration file has been fully parsed.
39 % referentie maken naar plug-in mechanisme van de linux kernel
40 % snelle, beproefde methode om met plug-ins te werken
43 \subsection{Implementation challenges}
44 The \textit{dl} functions in C allow run-time linking of shared objects.
45 However, the dlsym() function, which returns a pointer to a symbol in a shared object returns these as data pointer.
46 ISO C forbids using these data pointers as function pointers.
47 It's actually undefined behaviour according to the ANSI C \cite{Schildt:AAC90} standard, which results in warnings from the compiler.
48 Luckily, on all tested platforms this proved to be supported.
50 Setting the module path from the configure script was done using M4 macros.
51 % mist uitleg dat een plug-in een shared object is.
52 % veranderingen tussen de originele plugin manager en deze
53 % de keuzes van datastructure en voor opbouw van PM
54 % motiviatie en constructie van PM
55 % BUT WHY?!
57 \section{Attribute \& Obligation Store}
58 % recap doel AOS
59 For each element of data some meta-data needs to be recorded.
60 In the first implementation, this was expressed in a structure which held \ldots
61 % parent/child relatie
63 \begin{itemize}
64 \item the label associated with the data
65 \item the data type
66 \item a flag indicating whether the data needs to be freed when cleaning up
67 \item the plug-in the data belongs to
68 \end{itemize}
70 \subsection{Unforeseen shortcomings}
71 The data store needed a way to handle permissions.
72 To attribute ownership of data to a plug-in, the memory address of the setting plug-in has been used.
73 This provides a reliably unique identifier, which can be used to prevent data from being deleted by plug-ins other than the setting plug-in.
75 After the original design was proposed, it became apparent that a way to express parent/child relationships was needed for more efficient use of the data store.
76 While adding these fields to the data structures was easy, designing an elegant API to expose this functionality to plug-ins was conceptually quite hard.
77 Please see section \ref{plugin_api} for the proposed API to handle relations.
79 % parent/child als iteratie
80 % permissions als iteratie
81 % deletable als iteratie
82 % na 3 iteraties erachter komen dat het een binaire boom moet worden
83 % heeft eventueel nog wat motivatie nodig
84 % welke keuzes heb je gemaakt en waarom
85 % welk doel heb je geprobeerd te volgen
86 % speciale type afhandeling (ideeen erover en wat te doen)
87 % kun je over schrijven dat je bijv speciale types wilt kunnen zoeken
89 \subsection{Implementation challenges}
90 % zoekalgoritme dingen, hoe om te gaan met verschillen tussen plug-ins en de eef api
91 % plug-ins moeten inspelen op exterene saml2xacml2 formattering om iets nuttigs te kunnen doen
92 The first implementation of the AOS used an array of structs, whose size was increased at each setting operation.
93 This proved to be really hard to work with, not to mention very inefficient when data gets deleted.
94 The solution to this was using a linked list.
95 It is always the same size, and doesn't waste memory when deleting nodes from the list.
97 %\subsection{Tools}
98 %The POSIX syslog functionality seemed the only viable option to facilitate logging.
100 \section{Integration of build environment}
101 I have configured a 'make check' target that acts as a hook into the DejaGNU testing framework.
102 %TODO cite dejagnu
103 The LICENSE file present in the project directory will be prepended to all code files in the distribution directory created by 'make dist'.
104 The API documentation of the internal logic of the EEF can be generated by using Doxygen to parse annotations in the C code.

ViewVC Help
Powered by ViewVC 1.1.28