28 lines
2.4 KiB
TeX
28 lines
2.4 KiB
TeX
\chapter{Implementation}
|
|
|
|
This chapter describes the software design and architecture, and the way that they help to solve the problem. The following sections describe the FUSE framework, different methods used to store access permissions of processes and the way the chosen architecture is designed to resist unauthorised access to the filesystem.
|
|
|
|
\section{FUSE framework}
|
|
\label{impl:fuse}
|
|
|
|
In order to control the filesystem operations performed by the processes, ICFS uses FUSE (Filesystem in Userspace) framework\cite{FUSE} to override the filesystem call interface. FUSE allows to implement custom filesystems or layers in userspace, which makes it very flexible and easy to use. FUSE defines an API that can be implemented by the developers of the filesystems. After the implementation (which will be referred to as \emph{FUSE application}) is launched, it mounts its filesystem at the specified location, and replaces the filesystem calls with its own methods, according to the FUSE API.
|
|
|
|
ICFS implements the API in C, using libfuse3 library. It then launches the FUSE daemon through fuse\_main() function, which sets up the filesystem, and performs all the communication between the kernel and the FUSE application. FUSE does not directly replace syscalls, but instead communicates with the kernel via a special device in /dev directory, called /dev/fuse. This device uses a special protocol to communicate with the kernel and translate filesystem calls into FUSE API method invocations.
|
|
|
|
ICFS does not have a backing store (a separate filesystem that contains actual data). Instead, it uses the so-called passthrough mode, where filesystem calls are forwarded to the original filesystem, if access control policies allow them.
|
|
|
|
\subsection{Hiding the underlying directory}
|
|
|
|
\todo[inline, author={\textbf{Draft note}}]{Write how the source directory is protected}
|
|
|
|
\section{Permission tables}
|
|
|
|
\todo[inline, author={\textbf{Draft note}}]{Write how permission tables scheme was chosen}
|
|
|
|
\subsection{Temporary permissions}
|
|
|
|
\todo[inline, caption={Write how permission tables work}, author={\textbf{Draft note}}]{Write how temporary permission tables work. Specifically, how temporary permissions work with the cc library and start time process identification}
|
|
|
|
\subsection{Permanent permissions}
|
|
|
|
\todo[inline, caption={Write how permission tables work}, author={\textbf{Draft note}}]{Write how permanent permission tables work. Specifically, how permanent permissions work with sqlite3.} |