PERMISSIONS(5)
π PERMISSIONS(5) β the manual page for permissions, bestie π
okay so this is the permissions(5) man page β it's section 5, the file-formats girlies, and it's literally all about managing system-wide file permission settings. no cap, it's the glow-up guide for your files' ownership and vibes. β¨
πΈ NAME πΈ
permissions β manage system wide file permission settings π
π¦ SYNOPSIS π¦
The permctl(8) program sets permissions and ownerships of files according to the permission configuration files described in this manual page.
like. that's the whole plot. permctl reads these config files and then goes and does the thing. π
π DESCRIPTION π
π File Format π
The files /usr/share/permissions/permissions.* are line based and space delimited. Lines starting with # are comments. A file entry consists of a line of the format
/path/to/file user:group 0755
+capabilities cap_net_admin=ep
+acl user:somebody:rwx
okay so breaking down the columns, bestie:
- The first column specifies the file name. Directory names must end with a slash. (yes, the trailing
/is mandatory, don't @ me) - The second column specifies the file owner and group delimited by a
:character. - The third column specifies the file mode in octal.
Basic file entries can be extended by immediately following lines starting with +<keyword>. The following keywords are supported:
+capabilitiesβ grant Linux capabilities to the file. The string specified here must conform to the rules found incap_from_text(3).+aclβ grant additional access control list (ACL) entries to the file. The string specified here must conform to the rules found inacl(5)(section ACL TEXT FORMS). The ACL entries will be merged with the basic octal file mode, therefore they must not contain any permissions for the file owner, group or other. If a file has extended ACL entries assigned, but none are configured in the permissions configuration, the extended ACL entries will be removed bypermctl(8).
β οΈ real talk on that last one β if you've got extended ACLs on a file but they're not in the config, permctl(8) will remove them. so write them down or say bye-bye π
The file name in the first column of the base entry can contain contain variables as defined in the variables.conf file. A variable expands to one or more alternative path segments that relate to the same program or file. permctl will look in each possible path resulting from the variable expansion and apply the permissions accordingly.
(yes it really says "can contain contain" in the original, love that for us, typos are also main character energy π)
The variables.conf file will ignore empty lines, whitespace only lines or comment lines starting with #. All other lines must contain variable definitions that follow the syntax myvar = /path/1 /path/2. This example will declare a variable identified as myvar that will expand to both specified path segments.
Path segments appearing in variable assignments need to be separated by whitespace characters. The path values cannot contain whitespace themselves. The variable identifier is limited to alphanumeric characters and the underscore character.
To reference a variable in a permissions file, it needs to be dereferenced using the %{myvar} syntax. The variable needs to appear as a single path component and cannot be mixed with other literal characters. Multiple variables per path are allowed. The following are valid uses of variables:
- %{myvar}/sub/path
- /parent/path/%{myvar}
- /parent/path/%{myvar}/sub/path
- %{var1}/path/%{var2}
While the following are invalid:
- /prefix/pre%{myvar}suf/suffix
- /%{var}text/path
- /path/text%{var}
so like β variable has to be a whole path component, standing on its own, no sneaking it next to text. vibe check: passed or rejected, no in-between. π§
π Configuration File Locations π
The permctl program, when run in --system mode, will assemble a set of configuration entries depending on the profiles configured in /etc/sysconfig/security. The order of files parsed (with increasing priority) is as follows:
/usr/share/permissions/permissionsβ contains fixed entries independent of the active profile./usr/share/permissions/permissions.<profile>β contains the per-profile configuration of files./usr/share/permissions/packages.d/*β contains per-package drop-in configuration files, which can also exist in fixed or in different profile variants./etc/permissions.localβ contains local per-system extra entries or overrides managed by the system administrator.
each one higher priority than the last, so the local one gets the final word π that's your override era.
π Available Predefined Profiles π
The permissions package ships the following predefines profiles:
easyβ security settings targeted towards single user workstations, where the only user is also the administrator. This profile is tailored towards more simplicity (less configuration and authorization requirements) at the possible expense of security in some areas.secureβ this is a balanced profile for servers or multi-user workstations that contains more secure settings at the expense of additional configuration or authorization requirements in some areas.paranoidβ this is a profile that disables all setuid and setgid bits and most capabilities. It is intended for power users that want to add back individual setuid bits via the/etc/permissions.localfile. This profile is not intended to be used as-is, as it will likely break the system without careful tuning.
π do NOT just rawdog the paranoid profile. it will absolutely wreck your system if you don't carefully tune it first. it says so right there. i'm not being dramatic, the man page said it first.
β¨ EXAMPLES β¨
This is a demonstration of the use of variable expansion:
# in variables.conf
lib_dirs = /lib /lib64
sub_dirs = prog_v1 prog_v2
# in a permissions profile
%{lib_dirs}/%{sub_dirs}/libsomething.so root:root 04755
This will cause permctl to try and apply the given permission to all of the following paths, if existing:
/lib/prog_v1/libsomething.so
/lib64/prog_v1/libsomething.so
/lib/prog_v2/libsomething.so
/lib64/prog_v2/libsomething.so
like?? it just multiplies out every combo. 2 Γ 2 = 4 paths, she ate π₯ (and note the if existing β it only touches the ones that are actually there, okurrr)
π FILES π
/usr/share/permissions/permissions
/usr/share/permissions/permissions.easy
/usr/share/permissions/permissions.secure
/usr/share/permissions/permissions.paranoid
/usr/share/permissions/packages.d/*
/usr/share/permissions/permissions.d/* (deprecated)
/usr/share/permissions/variables.conf
/etc/permissions.local
heads up: /usr/share/permissions/permissions.d/* is deprecated π«Ά still listed, but she's retired.
π¦ SEE ALSO π¦
(that's the one, that's the only one, go read it next iykyk)
π AUTHORS π
Written by Ludwig Nussel. π«Ά ty king
β REPORTING BUGS β
Report bugs to https://bugzilla.suse.com/ or to https://github.com/openSUSE/permissions/.
bugs are not a vibe, so like, report them bestie π
and that's the page!! footer tea for the completionists: this is the PERMISSIONS(5) manual, came out 05/22/2024, section 5, and that's the whole thing. mwah πβ¨
π¦ where this page comes from
- opensuse-leap 16.0: permissions-config 1699_20250120-160000.2.2 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms