Update

accesscontrol.tex

@@ -7,7 +7,7 @@ By default, UNIX-like operating systems only provide simplistic Discretionary Ac
 
 The policy used by traditional UNIX systems is based on the concepts of \textit{file owner}, \textit{group of a file}, and \textit{others}. For each file, the access rights for these three categories can be specified independently using a so-called access mode. The access mode is a bitmask which specifies whether the file owner, the group of the file, and others have read, write, or execute permissions.
 
-Each process has it's own \textit{Effective User ID} (EUID), that identifies the user that initiated it. When a process tries to access a file, the kernel checks the access mode of the file, and grants or denies access based on the following rules:
+Each process has it's own \textit{Effective User ID} (EUID),  the user that the process is running on behalf of. When a process tries to access a file, the kernel checks the access mode of the file, and grants or denies access based on the following rules:
 
 \begin{itemize}
 	\item If the process's effective user ID matches the file owner, the file owner's access mode is used.
@@ -16,7 +16,7 @@ Each process has it's own \textit{Effective User ID} (EUID), that identifies the
 	
 \end{itemize}
 
-The access mode is stored in the file's inode, and is set by a process with the file owner's user ID using the \texttt{chmod} system call. The file owner is the user who created the file, and can be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser. The group of a file is set to the group of the file owner when the file is created, and can also be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser.
+The access mode is stored in the file's inode,  and can be changed by a process with the file owner's user ID using the \texttt{chmod} system call. The file owner is the user who created the file, and can be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser. The group of a file is set to the group of the file owner when the file is created, and can also be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser.
 
 Later, a feature called Access Control Lists (ACL) was introduced to many UNIX-like operating systems and eventually included in the POSIX standard. ACLs provide the ability to control file permissions of specific users, rather than just owner, group and others. Similar to the classic UNIX access control policies, only processes running with the user ID that matches the owner user ID of a file can change its ACLs.
 

evaluation.tex

@@ -14,46 +14,58 @@ We tried to asses the quality of ICFS by the following metrics:
 
 For performance and usability tests, we used an HP Pavilion Laptop 15-cc563st with an Intel® Core™ i7-7500U processor, a Western Digital WDS250G2B0B WD Blue 3D NAND internal M.2 SATA SSD and 12 GB of DDR4 RAM, running Fedora Linux 42 (Workstation Edition) with Linux 6.14.5-300.fc42.x86\_64 kernel, GNOME 48 desktop environment with Wayland window session.
 
-
 For additional compatibility tests, a KVM virtual machine running on the same laptop was used. The OS on the virtual machine was Debian GNU/Linux 12 (bookworm) x86\_64 with 6.1.0-27-amd64 kernel, GNOME 43.9 with X11 windowing system. The virtual machine was given 2 CPU cores and 2 GB of RAM.
 
+To assess the qualities of ICFS during regular usage, we have mounted it to a directory pre-filled with files, and attempted to access the files with different software. While trying to simulate common use-case scenarios, we tested the following programs' compatibility and usability with ICFS:
+
+\begin{itemize}
+	\item {\TeX}studio.
+	\item Programming IDE/text editor (Neovim).
+	\item A web browser (Mozilla Firefox).
+	\item File manager (GNOME Files, also known as Nautilus).
+	\item File synchronisation software (Syncthing).
+	\item Standard command line core utilities (e.g. \verb|ls|, \verb|cd|, \verb|grep|, ...).
+\end{itemize}
+
+We chose these programs not only because of their commonality, but also since they exhibit fairly diverse patterns of filesystem usage that are relevant in practice.
+
+\iffalse
+
+For performance testing, special scripts were written, that test the speed of `open` operations. We did not test other operations, since 
+
+\fi
+
 \todo[inline, caption={Complete Evaluation}, author={\textbf{Draft note}}]{The rest of this chapter is \emph{very} incomplete, and only contains a brief and informal talk about the issues I am facing right now. This is not the actual thesis-worthy text. All issues discussed were relevant as of 13.05.2025} 
 
-In this chapter presents the method of evaluating the solution is presented, and the found qualities of the solution are discussed.
+\section{Security}
-
-Specifically will include:
-\begin{itemize}
-	\item ,,Does the solution actually solve the problem?''
-	\item Interoperability with other software: does using this fs break other programs, like whether it interferes with programs using auxiliary files, usability of terminal programs (\verb|grep| is a particularly nasty one for this specific project).
-	\item Performance and overhead.
-	\item Security considerations.
-\end{itemize}
 
+\todo[inline, author={\textbf{Draft note}}]{What to even say here?}
 
 \section{Usability}
 
-While it is difficult to put an objective score on the usability of any system, we decided to measure the usability of ICFS by the amount 
+While it is difficult to put an objective score on the ease of use of any system, we measure the usability of ICFS by the amount of dialogues the user has to consciously react to while using the system. 
 
-\say{does using this fs break other programs?}
+In our testing we found that most programs' filesystem usage was quite manageable with ICFS. {\TeX}studio and Neovim only required the user to interact with a single dialogue when opening existing projects, and none when creating new files.
-\newline
 
-\sout{Mostly - no. The biggest issue right now are (ironically) file trackers like tracker-miners. Those are programs that scan the filesystem (e.g. to make file search more efficient). The problem is that the current version of the software does not allow changing the scope of permissions you are giving (e.g. you can't just give permission to access the entire filesystem).
+The file manager Nautilus generally did not require any access permissions to function, but generated more dialogues than initially expected. When started, Nautilus opened files to scan them to display mini-previews of their contents.
 
-The solution would be to give an ability to adjust the scope inside the permission dialogue. Everything on the ``backend'' side is ready for this change, but... since I am using zenity it does not easily give me the ability to just add another element to the dialog. Probably a custom dialogue program has to be written, or multiple dialogues would have to be shown(e.g. standard one with Allow/Allow this time/Deny with a ``more options'' button, and then a second zenity dialogue with more detailed configurations) to solve the issue.}
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.6\linewidth]{./images/picture-preview-nautilus.png}
+	\caption{Example of a picture mini-preview: image on the left is the scaled-down version of the actual image stored in the file.}
+\end{figure}
 
-Now it does not.\newline
+So, for every image to be scanned, a permission was required. It might seem like a simple problem to solve at first: after all if the user gives even a temporary permission to the entire folder, all images should open seamlessly. The issue is, that Nautilus uses another program (gdk-pixbuf-thumbnailer) to scan images on its behalf, one image at a time. Hence, every temporary permission given to that program, will only last until the next image is opened. One practical solution to this problem is to give gdk-pixbuf-thumbnailer a permanent permission to access the folder in question.
 
-\say{..like whether it interferes with programs using auxiliary files..}
+The web browser used the filesystem only when a file was downloaded and consequently needed saving. To select the path for the file, web browsers use file selection dialogues provided by the system file manager.
-\newline
 
-No, this issue is solved. Because the programs that use such files are typically the ones that create them, they automatically get the permissions to access them.
+\begin{figure}[H]
-
+	\centering
-In fact, I am writing this thesis inside of a folder managed by ICFS, and even despite TeX's notorious love for auxiliary files it works just fine.\newline
+	
-
+	\includegraphics[width=\linewidth]{./images/file-selection-dialogue.png}
-\say{..usability of terminal programs (grep is a particularly nasty one for this specific project)}
+	
-\newline
+	\caption{}
-
+\end{figure}
-\sout{Yes, this still is an issue. The problem of grep is the same as with file trackers, so I will skip it.}
 
 This is mostly solved in my experience. It wasn't as annoying to use the terminal programs as I initially expected.
 

motivation.tex

@@ -65,7 +65,7 @@ Overall, there appears to be little research on systems that actively involve us
 
 \section{Requirements for the solution}
 
-\todo[inline, author={\textbf{Draft note}}]{Negate the statements? (state what we want, not what we don't want)}
+%\todo[inline, author={\textbf{Draft note}}]{Negate the statements? (state what we want, not what we don't want)}
 
 The key issues with existent solutions, that our the system proposed in this thesis will try to address are as follows:
 \begin{itemize}