feat(drive): add /api/drive

- permit shared drive creation from oxicloud admin (for now)
    - prepare other personal drive creation (Not implemented), need to validate
    quota policies and strategy first
    - add hurl test to verify permissions
This commit is contained in:
Edouard Vanbelle
2026-06-23 23:16:02 +02:00
parent 184520c17a
commit a5b24a7453
11 changed files with 1181 additions and 28 deletions
@@ -25,18 +25,134 @@ use uuid::Uuid;
use crate::application::ports::authorization_ports::AuthorizationEngine;
use crate::common::errors::DomainError;
use crate::domain::repositories::drive_repository::DriveRepository;
use crate::domain::repositories::subject_group_repository::SubjectGroupRepository;
use crate::domain::services::authorization::{Grant, Permission, Resource, Role, Subject};
use crate::infrastructure::repositories::pg::DrivePgRepository;
use crate::infrastructure::repositories::pg::SubjectGroupPgRepository;
use crate::infrastructure::services::pg_acl_engine::PgAclEngine;
pub struct DriveManagementService {
drive_repo: Arc<DrivePgRepository>,
authz: Arc<PgAclEngine>,
/// Needed to validate that a Group owner subject is non-empty at
/// create-drive time — refusing creation with an empty group avoids
/// constructing an orphan-owned drive (the "drive must always have
/// ≥1 effective Owner-user" invariant from day one).
group_repo: Arc<SubjectGroupPgRepository>,
}
impl DriveManagementService {
pub fn new(drive_repo: Arc<DrivePgRepository>, authz: Arc<PgAclEngine>) -> Self {
Self { drive_repo, authz }
pub fn new(
drive_repo: Arc<DrivePgRepository>,
authz: Arc<PgAclEngine>,
group_repo: Arc<SubjectGroupPgRepository>,
) -> Self {
Self {
drive_repo,
authz,
group_repo,
}
}
/// `POST /api/drives` — create a shared drive owned by a group.
///
/// **AuthZ (D3a)**: OxiCloud-admin only. The plan (`drive.md §6`)
/// reads "admin or group owner triggers" — D3a starts with the
/// admin-only path; group-owner triggering can extend the gate
/// later without changing the wire shape or the service method
/// signature. `caller_is_admin` is resolved by the HTTP handler
/// from `CurrentUser.role` and passed in; the service trusts it
/// (defense-in-depth check stays at the route layer).
///
/// Audit log: `drive.created` with the drive id, the owner group,
/// and the granted_by (the admin caller).
pub async fn create_shared_drive(
&self,
caller_id: Uuid,
caller_is_admin: bool,
name: &str,
owner_subject: Subject,
quota_bytes: Option<i64>,
) -> Result<crate::domain::repositories::drive_repository::DriveWithRootName, DomainError> {
if !caller_is_admin {
tracing::info!(
target: "audit",
event = "drive_create.rejected",
reason = "not_admin",
caller_id = %caller_id,
owner_type = owner_subject.type_str(),
owner_id = %owner_subject.id(),
"👮🏻‍♂️ refused shared-drive create: caller is not an OxiCloud admin",
);
return Err(DomainError::access_denied(
"Drive",
"Only OxiCloud administrators can create shared drives.",
));
}
// Token subjects are share-link identities, not entities that can
// own things. Refuse at the service edge.
if matches!(owner_subject, Subject::Token(_)) {
tracing::info!(
target: "audit",
event = "drive_create.rejected",
reason = "invalid_owner_kind",
caller_id = %caller_id,
owner_type = "token",
"👮🏻‍♂️ refused shared-drive create: owner cannot be a Token subject",
);
return Err(DomainError::validation_error(
"Drive owner must be a user or a group, not a token.",
));
}
// Group owners must be non-empty — otherwise the drive is created
// with no transitive Owner-user from day one. Per Ed's invariant:
// "a drive must always remain with at least one Owner-user". User
// owners trivially satisfy this.
if let Subject::Group(gid) = owner_subject {
let n = self.group_repo.count_members(gid).await.map_err(|e| {
DomainError::internal_error("Drive", format!("group lookup failed: {e:?}"))
})?;
if n < 1 {
tracing::info!(
target: "audit",
event = "drive_create.rejected",
reason = "owner_group_empty",
caller_id = %caller_id,
owner_group_id = %gid,
"👮🏻‍♂️ refused shared-drive create: owner group has no members",
);
return Err(DomainError::validation_error(
"Owner group has no members — the drive would have no effective Owner.",
));
}
}
let trimmed = name.trim();
if trimmed.is_empty() {
return Err(DomainError::validation_error("Drive name is required."));
}
let drive = self
.drive_repo
.create_shared_drive_atomic(trimmed, owner_subject, quota_bytes, caller_id)
.await
.map_err(|e| DomainError::internal_error("Drive", format!("create failed: {e:?}")))?;
tracing::info!(
target: "audit",
event = "drive.created",
kind = "shared",
drive_id = %drive.drive.id,
owner_type = owner_subject.type_str(),
owner_id = %owner_subject.id(),
granted_by = %caller_id,
"🆕 shared drive created '{}' owned by {} {}",
trimmed, owner_subject.type_str(), owner_subject.id(),
);
Ok(drive)
}
/// `GET /api/drives/{id}/members` — every role grant on the drive.
@@ -37,6 +37,13 @@ pub struct SubjectGroupService {
/// make it not dyn-compatible (matches the convention used by other
/// services in this layer).
user_storage: Arc<UserPgRepository>,
/// Used by `add_member` / `remove_member` to drop stale
/// `user_groups_cache` entries for affected users so newly-added
/// (or newly-removed) group memberships surface in the next
/// `expand_subject_for_listing` call instead of waiting out the
/// 30 s TTL. Without this, fresh group-mediated drive grants
/// don't appear in `/api/drives` for up to 30 s after `add_member`.
engine: Arc<crate::infrastructure::services::pg_acl_engine::PgAclEngine>,
}
impl SubjectGroupService {
@@ -44,11 +51,29 @@ impl SubjectGroupService {
repo: Arc<SubjectGroupPgRepository>,
pool: Arc<PgPool>,
user_storage: Arc<UserPgRepository>,
engine: Arc<crate::infrastructure::services::pg_acl_engine::PgAclEngine>,
) -> Self {
Self {
repo,
pool,
user_storage,
engine,
}
}
/// Returns the user IDs whose `user_groups_cache` entries need to
/// drop after a membership change on `member`. For `User` members
/// it's just that user; for nested `Group` members, every
/// transitive user under that child group inherits/loses the
/// parent-group ancestor, so all of them need invalidation.
async fn invalidation_targets(&self, member: GroupMember) -> Result<Vec<Uuid>, DomainError> {
match member {
GroupMember::User(uid) => Ok(vec![uid]),
GroupMember::Group(child_id) => self
.repo
.list_transitive_users(child_id)
.await
.map_err(map_repo_err),
}
}
@@ -331,6 +356,15 @@ impl SubjectGroupService {
map_repo_err(e)
})?;
// Drop stale cached subject expansions for every user who just
// inherited the new group as a transitive ancestor — otherwise
// group-mediated grants (e.g. shared-drive Owner via this
// group) wouldn't surface in the next `expand_subject_for_listing`
// call for up to 30 s.
for uid in self.invalidation_targets(member).await? {
self.engine.invalidate_user_groups_cache(uid).await;
}
tracing::info!(
target: "audit",
event = "group.member_added",
@@ -356,11 +390,80 @@ impl SubjectGroupService {
));
}
// Self-defense (D3a follow-up): a group can never drop to 0
// transitive users once seeded. Without this, an admin could
// empty a group that's the Owner of a shared drive, leaving the
// drive with no effective Owner (orphan-owned). Per Ed's
// conservative-by-default stance: enforce the invariant
// globally — not just for drive-owning groups — so anything
// else that grants groups semantic power (delegated permissions,
// mention targets, ...) is automatically protected.
//
// Pre-check is conservative: it computes the transitive user
// set BEFORE the remove and refuses when the removal would
// collapse it to 0. The edge case "user reachable via a nested
// group" is handled by `list_transitive_users` itself — if the
// user is still reachable via another path after this remove,
// they stay in the set on the post-state, so the check would
// pass on the next remove instead.
let users_before = self
.repo
.list_transitive_users(group_id)
.await
.map_err(map_repo_err)?;
if !users_before.is_empty() {
let would_be_empty = match member {
GroupMember::User(uid) => users_before.len() == 1 && users_before.contains(&uid),
GroupMember::Group(child_id) => {
// For child-group removal: would this drop the
// parent's transitive user set to 0? Look up the
// child's transitive users — if every user in the
// parent's set comes through the child, removing the
// child empties the parent.
let child_users = self
.repo
.list_transitive_users(child_id)
.await
.map_err(map_repo_err)?;
!child_users.is_empty() && users_before.iter().all(|u| child_users.contains(u))
}
};
if would_be_empty {
tracing::info!(
target: "audit",
event = "group.member_removed_rejected",
reason = "would_empty_seeded_group",
group_id = %group_id,
member = ?member,
by = %caller_id,
"👮🏻‍♂️ refused last-user removal from group {group_id} \
(groups must never drop to 0 transitive users once seeded — \
a drive-owning group going empty would orphan the drive)",
);
return Err(DomainError::new(
ErrorKind::InvalidInput,
"SubjectGroup",
"A group cannot have less than 1 user once seeded. \
Add another user before removing this one."
.to_string(),
));
}
}
self.repo
.remove_member(group_id, member)
.await
.map_err(map_repo_err)?;
// Symmetric to add_member: drop the cache for users whose
// expanded subject set just lost the parent group as an
// ancestor. Without this, a removed-from-group user keeps
// appearing as a transitive member in `expand_subject_for_listing`
// for up to 30 s, surfacing grants they no longer have.
for uid in self.invalidation_targets(member).await? {
self.engine.invalidate_user_groups_cache(uid).await;
}
tracing::info!(
target: "audit",
event = "group.member_removed",