/[pdpsoft]/trunk/grid-mw-security/ees/thesis/eef.tex
ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 952 by aramv, Fri Oct 16 10:08:37 2009 UTC revision 953 by aramv, Wed Oct 21 08:40:48 2009 UTC
# Line 1  Line 1 
1  \chapter{Implementation of EEF components}  \chapter{Implementation of EEF components}
2    
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.  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.  This proved to be a very natural way to use C for large projects.
6  % kan uit requirements  % kan uit requirements
 % waarom autotools, doxygen, lex, yacc en dejagnu  
 % stukje over portability  
7  % welke platformen reeds getest  % welke platformen reeds getest
8    
9  I have tried to adhere to Unix-philosophy when creating the EEF.  I have tried to adhere to Unix-philosophy when creating the EEF.
 The project was created using GNU Autotools, Doxygen, Lex and Yacc.  
10  The configure script allows enabling debug output and specifying a modules path, where plug-ins should be loaded from.  The configure script allows enabling debug output and specifying a modules path, where plug-ins should be loaded from.
11    
 I have provided a 'make check' target using the DejaGNU testing framework.  
 The LICENSE file present in the project directory will be prepended to all code files in the distribution directory created by 'make dist'.  
   
12  \section{Evaluation Manager}  \section{Evaluation Manager}
13  This component is directly descended from LCMAPS, because the grammar of the configuration file should be identical.  This component is directly descended from LCMAPS, because it was possible to reuse the parser thanks to its loose coupling.
14  It was immediately apparent that the best way to ensure backwards-compatibility with existing configuration files was to just adopt the parser from LCMAPS, which is written in Lex and Yacc.  I have implemented the callback functions needed by the parser from scratch because the EEF is structured differently than LCMAPS.
15  I have implemented the callback functions needed by the parser from scratch.  However, I have reused the data structures for describing policies from LCMAPS.
 % WHY!  
 % Geen nieuwe datastructuren?  
 % waarom eigenlijk nog PDl behouden?  
 % vertel dat het voor sysadmins hetzelfde 'aanvoelt'  
16    
17  \subsection{Implementation challenges}  \subsection{Implementation challenges}
18  The Lex and Yacc code is interpreted to create pure C.  The Lex and Yacc code is interpreted to create pure C.
19  These output files will eventually be shipped with the software source package.  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 macro's.  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.  This information is then used to define a constant, upon which conditional compilation of the cleanup function of the Evaluation Manager can occur.
22    
23  In general, I've found the parser code I inherited from LCMAPS to be really difficult to read.  I've found the parser code inherited from LCMAPS to be really difficult to read.
24  This made implementing new callbacks quite difficult.  This made implementing new callbacks quite difficult.
25  Unfortunately there was no better option.  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?!  % WHY?!
28  % vertel dat alles behalve de parser nieuw is, ipv andersom  % vertel dat alles behalve de parser nieuw is, ipv andersom
29    
30  \section{Plug-in Manager}  \section{Plug-in Manager}
31  This component is possibly the most intricate, as it requires linking to code at run-time.  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.
34    
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.  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  % referentie maken naar plug-in mechanisme van de linux kernel
40  % snelle, beproefde methode om met plug-ins te werken  % snelle, beproefde methode om met plug-ins te werken
41    
42    
43  \subsection{Implementation challenges}  \subsection{Implementation challenges}
44  ANSI C has a set of functions that allow run-time linking of shared objects.  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.  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, which results in warnings from the compiler.  ISO C forbids using these data pointers as function pointers.
47  Luckily, on all tested platforms this proved to be completely supported.  It's actually undefined behaviour according to the ANSI C \cite{Schildt:AAC90} standard, which results in warnings from the compiler.
48  Setting the module path from the configure script was done using M4 macro's  Luckily, on all tested platforms this proved to be supported.
49    
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.  % mist uitleg dat een plug-in een shared object is.
52  % veranderingen tussen de originele plugin manager en deze  % veranderingen tussen de originele plugin manager en deze
53  % de keuzes van datastructure en voor opbouw van PM  % de keuzes van datastructure en voor opbouw van PM
# Line 56  Setting the module path from the configu Line 57  Setting the module path from the configu
57  \section{Attribute \& Obligation Store}  \section{Attribute \& Obligation Store}
58  % recap doel AOS  % recap doel AOS
59  For each element of data some meta-data needs to be recorded.  For each element of data some meta-data needs to be recorded.
60  This was expressed in a structure which holds (among other things) \ldots  In the first implementation, this was expressed in a structure which held \ldots
61  % parent/child relatie  % parent/child relatie
62    
63  \begin{itemize}  \begin{itemize}
# Line 65  This was expressed in a structure which Line 66  This was expressed in a structure which
66  \item a flag indicating whether the data needs to be freed when cleaning up  \item a flag indicating whether the data needs to be freed when cleaning up
67  \item the plug-in the data belongs to  \item the plug-in the data belongs to
68  \end{itemize}  \end{itemize}
69    
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.
74    
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.
78    
79  % parent/child als iteratie  % parent/child als iteratie
80  % permissions als iteratie  % permissions als iteratie
81  % deletable als iteratie  % deletable als iteratie
# Line 78  This was expressed in a structure which Line 89  This was expressed in a structure which
89  \subsection{Implementation challenges}  \subsection{Implementation challenges}
90  % zoekalgoritme dingen, hoe om te gaan met verschillen tussen plug-ins en de eef api  % 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  % 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, which size was increased at each setting operation.  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 read and maintain, not to mention very inefficient when data gets deleted.  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.  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.  It is always the same size, and doesn't waste memory when deleting nodes from the list.
96    
 To attribute ownership of data to a plug-in, the memory address of the setting plug-in was used.  
 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.  
   
97  %\subsection{Tools}  %\subsection{Tools}
98  %The POSIX syslog functionality seemed the only viable option to facilitate logging.  %The POSIX syslog functionality seemed the only viable option to facilitate logging.
99    
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.
105    

Legend:
Removed from v.952  
changed lines
  Added in v.953

grid.support@nikhef.nl
ViewVC Help
Powered by ViewVC 1.1.28