Linux File Permissions | Into the Terminal 105

Linux is by its nature fairly secure and that foundation starts all the way at the user and permissions level. Join us for Into the Terminal as we take a look at file ownership and permissions. Commands like chown and chmod shape the basis of every SysAdmin’s toolbox.
- - - - -
Critical Administration Skills for Red Hat Enterprise Linux: Whether you are new to Linux or new to RHEL, join our hosts for a hands-on look into the commands and processes, ask questions, and grow your knowledge.
Get Started with Red Hat Enterprise Linux: developers.redhat.com/register
Try it for yourself: redhat.com/interactive-labs
Continue the conversation: / redhat
Nate Lager: / gangrif
Scott McBrien: / stabby_mc
Commands used:
ls, chmod
Chapters
00:00 Stream start
00:21 Introduction
00:49 Change mode
04:01 Welcome
05:33 Why are permissions important?
16:01 Types of file permissions
20:56 Directory permissions
25:49 Changing ownership
29:41 Octal permissions
35:41 Permissions in action
45:46 Wrap up

[@queenannsrevenge100]

I could see Nate showing up at Summit in a Red Three-piece suit, rockin’ the Red Fedora and sunglasses as “ZZ Nate” 😂

[@boubou40]

i will be here next week, i'm always struggling with special permissions and acls

[@muhammadshahzad6151]

tell some about SUID and how to assign a SUID as a root so other user can execute it by the permission of user root

[@scottmcbrien6535]

We'll be covering SUID, SGID, and STVX (and filesystem acls, and apparently umask [thanks Nate!]) in our next episode. That said, SUID binaries are generally frowned upon, in fact, most security standards have mounting filesytems with the nosuid mount option as part of their standard.
A more modern approach to this problem is containerization. Podman runs rootless (meaning regular people can use it), but within the containers they make, they are offered 'root' shells. In reality, the container host processes still run as their unpriviledged accounts, however inside of their containerized environment, they're given full administrative control. So if someone needs to do something like ... run a webserver or bind a service to a port, they can do that within their container's environment using their containerized root authority.
Why is SUID frowned upon? Because you have to account for EVERY.SINGLE.THING that person might do with that application being root. Lets say, for example, you put SUID on the vim executable, thinking that it would allow someone to edit files as root. It works! But it also allows them to use :!/bin/bash and now get a bash shell from which they can do any other activity on the system as root. 😞 The SUID programs that come with the system are very task driven and have been through a ton of hardening, code review, and time-in-use (like the /usr/bin/passwd program). You should be wary of new SUID programs or people asking for you to make other programs SUID.

[@grahamcrawley2639]

If you remove x from /usr/bin/chmod, reapply it with setfacl ?

[@scottmcbrien6535]

Could potentially work, to grant back x to root who could then use chmod to change the mode of the file again. Personally I would re-install core-utils as my solution.

[@grahamcrawley2639]

So why did --- --- rwx not work, surely that gives everyone rwx permissions to the file ?

[@scottmcbrien6535]

Because it's not really "everyone". When someone interacts with a file, the order of operations is:
Is this the owner of the file? Then apply 'user' permissions
If not, is this someone in the group that owns the file? Then apply 'group' permissions.
The 'others' permissions apply to everyone who is neither the owner nor a group member of the group owner of the file. As a result 'everyone' is not really an accurate description of the people managed by the final field of permissions.