ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 953 - (hide annotations) (download) (as text)
Wed Oct 21 08:40:48 2009 UTC (12 years, 7 months ago) by aramv
File MIME type: text/x-latex
File size: 6200 byte(s)
One to beam up
1 aramv 928 \chapter{Implementation of EEF components}
3 aramv 953 \section{Programming philosophy}
4 aramv 928 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 aramv 936 % kan uit requirements
7     % welke platformen reeds getest
8 aramv 928
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 aramv 953 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.
16 aramv 928
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 aramv 953 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 aramv 928 This information is then used to define a constant, upon which conditional compilation of the cleanup function of the Evaluation Manager can occur.
23 aramv 953 I've found the parser code inherited from LCMAPS to be really difficult to read.
24 aramv 928 This made implementing new callbacks quite difficult.
25 aramv 953 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 aramv 936 % WHY?!
28     % vertel dat alles behalve de parser nieuw is, ipv andersom
29 aramv 928
30     \section{Plug-in Manager}
31     This component is possibly the most intricate, as it requires linking to code at run-time.
32 aramv 953 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 aramv 928 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 aramv 953 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 aramv 936 % referentie maken naar plug-in mechanisme van de linux kernel
40     % snelle, beproefde methode om met plug-ins te werken
41 aramv 928
42 aramv 953
43 aramv 928 \subsection{Implementation challenges}
44 aramv 953 The \textit{dl} functions in C allow run-time linking of shared objects.
45 aramv 928 However, the dlsym() function, which returns a pointer to a symbol in a shared object returns these as data pointer.
46 aramv 953 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 aramv 936 % 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?!
56 aramv 928
57     \section{Attribute \& Obligation Store}
58 aramv 936 % recap doel AOS
59     For each element of data some meta-data needs to be recorded.
60 aramv 953 In the first implementation, this was expressed in a structure which held \ldots
61 aramv 936 % parent/child relatie
62 aramv 928
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}
69 aramv 953
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 aramv 936 % 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
88 aramv 928
89     \subsection{Implementation challenges}
90 aramv 936 % 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 aramv 953 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 aramv 928 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 aramv 936 %\subsection{Tools}
98     %The POSIX syslog functionality seemed the only viable option to facilitate logging.
99 aramv 928
100 aramv 953 \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