We all hope for this thesis. Hopefully, the final commit.

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),  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:
+Each process has its 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.

evaluation.tex

@@ -55,7 +55,7 @@ Firefox interactions were limited to file downloads and uploads, which utilise s
 
 Hence, it inherited all the usability issues Nautilus had. This dependency also introduced security implications discussed in the following section.\footnote{Only the Flatpak version of Firefox was affected.}
 
-Impact on shell script usability was significant. Since each shell command spawns a new process, users must grant permissions for every command individually.\footnote{Permanent permissions for core shell utilities are discouraged, as they expose the filesystem to unrestricted access via these tools.} A partial mitigation involved redirection operators (\verb|>|, \verb|>>|), which force the shell interpreter to handle file operations, allowing child processes to inherit permissions. However, this approach breaks compatibility with existing scripts. This limitation was anticipated, and potential solutions are discussed in \autoref{eval:future}.
+Impact on shell scripting and command line tools' usability was significant. Since each shell command spawns a new process, users must grant permissions for every command individually.\footnote{Permanent permissions for core shell utilities are discouraged, as they expose the filesystem to unrestricted access via these tools.} A partial mitigation involved redirection operators (\verb|>|, \verb|>>|), which force the shell interpreter to handle file operations, allowing child processes to inherit permissions. However, this approach breaks compatibility with existing scripts. This limitation was anticipated, and potential solutions are discussed in \autoref{eval:future}.
 
 \section{Security}
 \label{eval:sec}
@@ -64,13 +64,13 @@ The analysis of ICFS’s security profile reveals a significant reduction in sec
 
 But while ICFS represents a significant improvement over traditional access control systems in single-user environments, its design contains notable limitations.
 
-ICFS theoretically allows users to control every filesystem access operation, but the system's security depends heavily on the user's ability to interpret and respond to access requests. Despite efforts to make the interface accessible, the system generates prompts that may confuse average users. For example, access attempts by Apostrophe were displayed as actions by \verb|/usr/bin/python3.12|. This occurs because Apostrophe is written in Python, an interpreted language: all Python programs execute under the Python interpreter, causing dialogues to display the interpreter path rather than the application name. This limitation stems from ICFS's permission system, which tracks processes at the executable level. Users must understand this behavior to avoid inadvertently granting interpreters permanent access to files, which would expose them to all scripts executed by the interpreter.
+ICFS theoretically allows users to control every filesystem access operation, but the system's security depends heavily on the user's ability to interpret and respond to access requests. Despite efforts to make the interface accessible, the system generates prompts that may confuse average users. For example, access attempts by Apostrophe were displayed as actions by \verb|/usr/bin/python3.12|. This occurs because Apostrophe is written in Python, an interpreted language: all Python programs execute under the Python interpreter, causing dialogues to display the interpreter path rather than the application name. This limitation stems from ICFS's permission system, which tracks processes at the executable level. Users must understand this behaviour to avoid inadvertently granting interpreters permanent access to files, which would expose them to all scripts executed by the interpreter.
 
 Another challenge arises with Flatpak-packaged applications, which often obscure filesystem paths within their sandboxes. For instance, Syncthing's relocated executable path invalidated \verb|/proc/pid/exe|, the mechanism ICFS uses to resolve process identities via the \verb|readlink| system call. Current implementations rely on unvalidated paths returned by \verb|readlink|, leaving the system vulnerable to attacks where malicious processes mask their identity by manipulating sandboxed paths.
 
 A functional limitation arises with the \verb|xdg-desktop-portal| daemon, which centralises file-chooser interfaces across desktop environments to streamline user interactions. By design, this daemon handles file operations on behalf of requesting processes via D-Bus, acting as an intermediary that abstracts filesystem access. While this improves compatibility and user experience, it introduces a challenge for ICFS: the daemon obscures the identity of the originating process, making it difficult to enforce granular access control tied to specific applications.
 
-For example, files created or accessed through \verb|xdg-desktop-portal| inherit permissions based on the daemon itself rather than the requesting application. This creates a trade-off between usability and precision in access control. To somewhat mitigate unintended access, the \verb|--no-perm-on-create| flag disables automatic permission grants during file creation.\footnote{That is, the file creation operation will still be completed, but the requested process will gain no permissions to access the file next time.}
+For example, files created or accessed through \verb|xdg-desktop-portal| inherit permissions based on the daemon itself rather than the requesting application. This creates a trade-off between usability and precision in access control. To somewhat mitigate unintended access, the \verb|--no-grant-on-create| flag disables automatic permission grants during file creation.\footnote{That is, the file creation operation will still be completed, but the requested process will gain no permissions to access the file next time.}
 
 However, the daemon retains user-driven file selection via graphical interfaces, maintaining safety equivalent to ICFS's core model (as both depend on GUI interactions remaining inaccessible to untrusted processes). This highlights a broader design constraint: similar trade-offs may exist when integrating with existing or ecosystem-wide services that centralise filesystem access.