Why a Nix-like system is a poor fit Nix manages software packages and user environments on a server, not permissions for web application users. Its security model prevents users from interfering with each other's installed packages, but it doesn't align with the needs of a modern website's access control.

A website's RBAC system requires the following:

    Separation of concerns: The database tracks user, role, and permission relationships, which are enforced by the website's application logic.
    Dynamic access control: Permissions are checked in real-time when a user requests a web page or resource.
    User lifecycle management: Processes for onboarding, offboarding, and updating permissions are handled through the application's user management interface, not the underlying server's groups. 

Attempting to force a Nix-like group system onto a web application would involve a series of problematic workarounds:

    Complex integration: You would have to bridge your web application's user authentication with the server's user and group management, a non-standard and difficult process.
    Weak security: Website authorization would depend on whether a user has a specific server group. An attacker who compromises a user's web account could gain access to the underlying server and its filesystem, potentially compromising other users' access via the server's group structure.
    Administrative burden: Any change to a user's access level would require a manual server-side update, which is slow and error-prone. In contrast, a proper RBAC system allows administrators to manage permissions through a simple UI.
    Unscalable architecture: A website's users are not the same as a server's users. As your website grows, manually managing permissions for every customer, user, or client on the server level is not feasible. 

How a proper website RBAC system works
A standard web application uses a database to track permissions, which are enforced by the application's own code. For example, a User may have a many-to-many relationship with a Role, and a Role has a many-to-many relationship with a Permission. 


    Components 
    	Description	Example
    User	An individual website account.	Alice, Bob, Charlie
    Role	A named set of permissions.	Admin, Editor, Contributor
    Permission	The right to perform a specific action.	can_edit_articles, can_publish_articles, can_delete_users


When a user tries to perform an action, the application performs an authorization check to see if the user's role has the necessary permission. 
This approach provides several advantages over a server-based group model:

    Scalability: The system is built for the application, so it can scale with your website's user base, not the underlying server's capacity.
    Security: The security boundary is within the application layer, preventing user access changes from introducing server-level vulnerabilities.
    Flexibility: You can define any number of roles and permissions without being limited by the server's group structure.
    Maintainability: All access management can be handled within the application's administration panel, not a server's command line