Missing audit event when changing Pages public access setting at group level

Summary

Changing the Pages visibility (pages_access_level) at the project level correctly creates an audit event (project_feature_pages_access_level_updated), but toggling the "Remove public access" setting (force_pages_access_control) at the group level does not produce any audit event.

This is a gap in audit event instrumentation for a security-relevant setting that affects all projects within a group and its subgroups.

Current Behavior

  • Project level: Changing Pages access level triggers project_feature_pages_access_level_updated audit event via Projects::ProjectFeatureChangesAuditor (ee/lib/projects/project_feature_changes_auditor.rb). This works correctly.
  • Group level: Toggling "Remove public access" (force_pages_access_control on NamespaceSetting) does not create an audit event. The column is explicitly excluded from Namespaces::NamespaceSettingChangesAuditor (ee/lib/namespaces/namespace_setting_changes_auditor.rb).

Root Cause

The force_pages_access_control column is not listed in EVENT_NAME_PER_COLUMN in ee/lib/namespaces/namespace_setting_changes_auditor.rb, and is explicitly placed in the denylist (columns_not_to_audit) in the corresponding spec (ee/spec/lib/namespaces/namespace_setting_changes_auditor_spec.rb, around line 127).

The flow is:

  1. Group update goes through Groups::UpdateService (EE override in ee/app/services/ee/groups/update_service.rb)
  2. On success, log_audit_events is called, which invokes Namespaces::GroupChangesAuditor
  3. GroupChangesAuditor delegates to Namespaces::NamespaceSettingChangesAuditor
  4. NamespaceSettingChangesAuditor only audits columns in its EVENT_NAME_PER_COLUMN hash, which does not include force_pages_access_control

Expected Behavior

Toggling the "Remove public access" setting for Pages at the group level should create an audit event, consistent with how project-level Pages access changes are audited.

Proposal

  1. Create a new audit event type file at ee/config/audit_events/types/group_force_pages_access_control_updated.yml:

    ---
name: group_force_pages_access_control_updated
description: A group's Pages public access control setting is updated
introduced_by_issue: <this issue URL>
introduced_by_mr: <MR URL>
feature_category: pages
milestone: '<current milestone>'
saved_to_database: true
streamed: true
scope: [Group]

  2. Add the column to EVENT_NAME_PER_COLUMN in ee/lib/namespaces/namespace_setting_changes_auditor.rb:

    force_pages_access_control: 'group_force_pages_access_control_updated'

  3. Update the spec in ee/spec/lib/namespaces/namespace_setting_changes_auditor_spec.rb:

    • Remove force_pages_access_control from the columns_not_to_audit denylist
    • Add a test case to the parameterized table: 
      :force_pages_access_control | false | true

  4. Regenerate audit event documentation:

    bundle exec rake gitlab:audit_event_types:compile_docs

Relevant Files

File Role
ee/lib/namespaces/namespace_setting_changes_auditor.rb Auditor that needs the new column entry
ee/spec/lib/namespaces/namespace_setting_changes_auditor_spec.rb Spec with denylist to update
ee/lib/projects/project_feature_changes_auditor.rb Reference: how project-level Pages audit works
ee/config/audit_events/types/project_feature_pages_access_level_updated.yml Reference: existing project-level audit event type
app/views/groups/settings/_pages_access_control.html.haml The group settings UI for "Remove public access"
app/controllers/concerns/groups/params.rb Where force_pages_access_control is permitted
ee/app/services/ee/groups/update_service.rb EE group update service that calls log_audit_events
Edited by 🤖 GitLab Bot 🤖