acl

Overview

acl provides utilities and library support for working with file system Access Control Lists (ACLs). In practical terms, it lets administrators and tools inspect, set, copy, restore, and validate ACLs on files and directories when traditional mode bits are not enough.

In a Linux distribution, this package usually matters wherever fine-grained file permissions are used. It is commonly useful on servers, shared systems, build hosts, and storage systems where access needs to be expressed more precisely than rwx bits alone.

Purpose and typical use cases

Typical use cases include:

• inspecting existing ACLs on files and directories;
• applying ACLs to shared directories or project trees;
• preserving ACLs during file operations or backups;
• restoring ACLs from saved text representations;
• validating ACL data in scripts or maintenance tooling.

Typical users include:

• system administrators managing shared storage or service accounts;
• developers who need reproducible permission handling in scripts;
• CI/CD maintainers who archive or restore file trees with ACL metadata;
• security engineers reviewing access rules on filesystems that rely on ACLs.

Upstream project

The upstream project is hosted on Savannah and documents acl as commands for manipulating POSIX Access Control Lists. The accompanying manual pages describe the command-line tools and library interfaces provided by the project. (savannah.nongnu.org)

Upstream reference:

• Savannah project page

Dist-git repository contents

This dist-git repository is organized as a standard RPM package repository:

• SPECS/ — RPM spec files and package metadata maintained by NiceOS;
• SOURCES/ — source-related metadata and manifest files used to track upstream inputs;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present for this package.

The Git repository does not store large upstream source archives directly. Those files are intentionally kept out of the repository, while source integrity is tracked through manifest files in SOURCES/.

Source storage and integrity policy

For this package, the important rule is that the repository records what upstream source is expected, but it does not carry the large archive payload itself.

Maintainers should treat the SOURCES/ manifests as the source-of-truth for integrity tracking. Before updating the package, verify that the manifest still matches the intended upstream source and that the packaging inputs are consistent with the spec file.

If the upstream project changes its release layout, file naming, signing method, or source packaging rules, NiceOS maintainers should verify the update procedure before relying on it.

NiceOS maintenance notes

Before updating this package, check:

• whether upstream changed the project structure or the recommended build/install flow;
• whether any patch carried in SPECS/ still applies cleanly;
• whether SOURCES/ manifests need regeneration after source replacement;
• whether SBOM/ content needs to be refreshed, if NiceOS keeps one for this package;
• whether file lists, license files, or installed paths changed in a way that affects the RPM spec;
• whether the update introduces behavior changes that matter for ACL handling, filesystem integration, or scripts that call these tools.

If any upstream detail is unclear from the repository contents, NiceOS maintainers should verify it before depending on it in production packaging.

Build and verification checklist

A practical maintainer checklist for this package:

• review the spec file for source and build changes;
• confirm the expected upstream source is represented in SOURCES/;
• rebuild the SRPM and RPM locally;
• run the package test or check phase, if the spec defines one;
• verify that installed binaries, libraries, and man pages match the package intent;
• check that file permissions, ownership, and ELF dependencies are as expected for the distribution policy;
• inspect %files entries for completeness and accidental omissions;
• test basic ACL functionality on a suitable filesystem, if the package update touches behavior in user-facing tools;
• review any SBOM or metadata updates before pushing the change.

References

• Savannah project page
• acl(5) manual page
• getfacl(1) manual page
• setfacl(1) manual page
• acl_check(3) manual page

Russian documentation

• README_RU.md

Dist-git repository notes

• Package repository: rpms/acl
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.