← RHCSA: RHEL 10 production administration
08 / 8 · 25 MIN

Shared permissions and SELinux

Distinguish group inheritance, access bits, and mandatory policy.

Concept and mechanism

In a shared directory with access already granted, setgid lets new files inherit the directory’s group. That does not by itself grant content-write access. Without a default ACL, umask removes bits from the mode requested by the application: requested 0666 with mask 0002 permits 0664. The application can request fewer permissions. The sticky bit controls deletion and renaming in the directory, not writes to each file’s contents. Test with the actual producer and consumer identities to confirm the design supports the workflow without unnecessary access.

Guided application

SELinux adds policy decisions that chmod alone does not resolve. A name_bind denial directs investigation toward the port and protocol type mapping; a file-context issue requires different analysis. chcon changes the current context, while restorecon applies persistent mappings. For a durable path exception, review the mapping with semanage fcontext and apply the expected context. A Boolean can grant broader capabilities; confirm its scope before persisting it with setsebool -P. Retain enforcement and validate the functional action after correction.

IN PRACTICE

A portal on a nonstandard port requires reviewing the port type. A new content directory requires reviewing file context. Both can fail despite correct Unix mode bits.

Common pitfalls

Confusing setgid and write access; using sticky as content permission; fixing ports with file labels; persisting Booleans without scope review.

Related topics: Tools, arguments, and reliable scripts · Software, RPM repositories, and Flatpak

Take this idea with you

Correct the identified mechanism and validate persistent configuration.

Create account

Reference: RHEL10 SELinux administration · EX200 based on Red Hat Enterprise Linux 10