About the Contributor and Mentors

This project is developed as part of Google Summer of Code 2025, in collaboration with the Department of Biomedical Informatics at Emory University.

Project Specifications

Institutional departments, such as the Biomedical Informatics (BMI) Department of Emory University School of Medicine, manage vast amounts of data, often reaching petabyte scales across multiple Linux-based storage servers. Researchers storing data in these systems need a streamlined way to modify ACLs to grant or revoke access for collaborators. Currently, the IT team at BMI is responsible for manually handling these ACL modifications, which is time-consuming, error-prone, and inefficient, especially as data volume and user demands grow.

To address this challenge at BMI and similar institutions worldwide, a Web Management Interface is needed to allow users to modify ACLs securely. This solution would eliminate the burden on IT teams by enabling on-demand permission management while ensuring security and reliability. The proposed system will feature a robust and highly configurable backend, high-speed databases, orchestration daemons for file storage servers, and an intuitive frontend.

Work done by the Contributor

1. Introduction / Overview

Vortex was designed to be a robust Linux ACL Management System capable of handling multiple file system servers and managing permissions for millions of files. This scalability and reliability were made possible through deliberate design decisions and a carefully chosen tech stack during the proposal phase.

As part of GSoC 2025, a fully functional version (v1.1) was developed, providing organizations with a practical and production ready interface for deploying a Linux ACL Management System. The project followed a systematic approach: starting with requirement gathering in close collaboration with mentors, moving on to prototyping, validation, and iteration, then submitting a detailed proposal, and finally building the complete system.

2. Project Architecture

Vortex is composed of three major components: the backend, frontend, and daemons (deployed on file system servers). After discussions with mentors, it was decided to maintain these components in separate repositories instead of a monorepo, allowing for faster, more atomic, and independent development.

Backend: The backend is the core of the system and the most critical component. It is responsible for orchestrating daemons, file system mounts, databases, and authentication; scheduling and processing transactions; ensuring fair, systematic scheduling across multiple cores; and maintaining reliability and consistency of the entire system.

Frontend: The frontend provides the user-facing interface for requesting file permission changes. It allows users to submit permission change requests and delegates all privileged operations to the backend, operating with minimal or no direct infrastructure privileges.

Daemons (ACL Core & ACL API): The daemon components run on the file system servers and are responsible for performing ACL modifications at the file level. They are deployed as systemd services, controlled entirely by the backend, and execute file level permission changes as instructed.

3. Development Phase

Before Midterm: The backend and daemon components were developed and completed based on the best possible estimations of the frontend's requirements.

After Midterm: Development shifted towards the frontend, along with its integration with the backend, ensuring smooth interaction between the components.

Documentation: The Docs repository was maintained consistently throughout the process.

4. Documentation

All components of the project are thoroughly documented in the official Docs repository. The documentation provides up to date reference material for both users and developers, covering not only individual components but also the interactions and workflows between them.

5. Summary

A complete Linux ACL Management System named Vortex was planned, built, and shipped throughout the GSoC period with the guidance from my mentors. It was indeed a very well spent summer!

Current State of the Project

While submitting the final report of the project, Vortex is capable of handling file permissions of millions of files distributed across multiple Linux file system servers. It provides a user-friendly interface for users to change the permissions of files they own.

Future Work

During the GSoC 2025 period, a working v1.1 of the project was developed and successfully launched. This release includes all the essential features required for a Linux ACL Management System to operate in a production environment. While the foundation is strong, there remains significant scope for improvements, optimizations, and additional features that can make the project even more powerful and user-friendly.

GSoC 2025 marked the birth of Vortex, and it will continue to be actively developed and maintained for the foreseeable future.

Challenges and Learnings

I officially kicked off this project the day I sent my first email to my mentors, 10 February 2025. Since then, I've been at it every single day. Some days were good, some went terrible. But if I had to capture the essence of my GSoC journey, the highs and the lows, I'd sum it up with three sections and quotes from the giants of computing who came before me.

1. Premature Optimizations

Before starting the project, I had well planned the timeline for each step of progress. The biggest challenge I faced which lagged me behind the timeline for a bit was during the phase where I got busy in optimizing everything to its core. At that time, I worked multiple hours, even on weekends to catch up with the timeline and over worked each and every module of the project.

That experience taught me an important distinction: optimization does matter. Writing efficient, clean, and scalable code is essential for building good software. But there's a balance to maintain. The real challenge is knowing how much optimization is practical at a given stage.

2. Writing Better Code than More Code

Writing code every day and steadily filling up a repository can feel productive and signal progress. But sheer volume of code isn't the true measure of progress. Often, real progress comes from carefully reviewing the codebase, finding better approaches, and removing unnecessary complexity.

In fact, some of the most valuable commits are the ones with more deletions than additions. Fewer lines can mean cleaner design, easier maintenance, and better performance.

3. Just Do It Approach

When tackling a coding problem, the biggest challenge often isn't the problem itself, it's how we approach it. Two common traps appear on opposite ends of the spectrum: overthinking and underestimating. Both cases stem from the same root cause: insufficient experience.

Instead of waiting for the "perfect plan," write something. Anything that moves you forward. The act of coding itself sharpens your understanding, reveals hidden complexities, and builds the very experience you lacked at the start.