Users and groups
Users and groups are used on GNU/Linux for access control—that is, to control access to the system’s files, directories, and peripherals. Linux offers relatively simple/coarse access control mechanisms by default. For more advanced options, see ACL, Capabilities and PAM#Configuration How-Tos.
Overview
A user is anyone who uses a computer. In this case, we are describing the names which represent those users. It may be Mary or Bill, and they may use the names Dragonlady or Pirate in place of their real name. All that matters is that the computer has a name for each account it creates, and it is this name by which a person gains access to use the computer. Some system services also run using restricted or privileged user accounts.
Managing users is done for the purpose of security by limiting access in certain specific ways. The superuser (root) has complete access to the operating system and its configuration; it is intended for administrative use only. Unprivileged users can use several programs for controlled privilege elevation.
Any individual may have more than one account as long as they use a different name for each account they create. Further, there are some reserved names which may not be used such as «root».
Users may be grouped together into a «group», and users may be added to an existing group to utilize the privileged access it grants.
Note: The beginner should use these tools carefully and stay away from having anything to do with any other existing user account, other than their own.
Permissions and ownership
The UNIX operating system crystallizes a couple of unifying ideas and concepts that shaped its design, user interface, culture and evolution. One of the most important of these is probably the mantra: «everything is a file,» widely regarded as one of the defining points of UNIX. This key design principle consists of providing a unified paradigm for accessing a wide range of input/output resources: documents, directories, hard-drives, CD-ROMs, modems, keyboards, printers, monitors, terminals and even some inter-process and network communications. The trick is to provide a common abstraction for all of these resources, each of which the UNIX fathers called a «file.» Since every «file» is exposed through the same API, you can use the same set of basic commands to read/write to a disk, keyboard, document or network device.
A fundamental and very powerful, consistent abstraction provided in UNIX and compatible operating systems is the file abstraction. Many OS services and device interfaces are implemented to provide a file or file system metaphor to applications. This enables new uses for, and greatly increases the power of, existing applications — simple tools designed with specific uses in mind can, with UNIX file abstractions, be used in novel ways. A simple tool, such as cat, designed to read one or more files and output the contents to standard output, can be used to read from I/O devices through special device files, typically found under the /dev directory. On many systems, audio recording and playback can be done simply with the commands, » cat /dev/audio > myfile » and » cat myfile > /dev/audio ,» respectively.
Every file on a GNU/Linux system is owned by a user and a group. In addition, there are three types of access permissions: read, write, and execute. Different access permissions can be applied to a file’s owning user, owning group, and others (those without ownership). One can determine a file’s owners and permissions by viewing the long listing format of the ls command:
total 13740 drwxr-xr-x 2 root root 4096 Jan 12 00:33 grub -rw-r--r-- 1 root root 8570335 Jan 12 00:33 initramfs-linux-fallback.img -rw-r--r-- 1 root root 1821573 Jan 12 00:31 initramfs-linux.img -rw-r--r-- 1 root root 1457315 Jan 8 08:19 System.map26 -rw-r--r-- 1 root root 2209920 Jan 8 08:19 vmlinuz-linux
The first column displays the file’s permissions (for example, the file initramfs-linux.img has permissions -rw-r—r— ). The third and fourth columns display the file’s owning user and group, respectively. In this example, all files are owned by the root user and the root group.
total 16 drwxrwx--- 1 root vboxsf 16384 Jan 29 11:02 sf_Shared
In this example, the sf_Shared directory is owned by the root user and the vboxsf group. It is also possible to determine a file’s owners and permissions using the stat command:
What is root CGROUP?
In the classic mode, which may ultimately be deprecated, but is still fully supported, there can be several separate cgroup hierarchies. Each hierarchy starts its life as a root cgroup, which initially holds all processes.
1 Answer 1
Your article is talking about «classic» vs. «unified» (cgroup v2) cgroups:
https://lwn.net/Articles/606699/
As was recently reported, the 3.16 Linux kernel will have under-development support for a so-called «unified hierarchy». The new ideas introduced with that development will not be discussed yet, as we cannot really appreciate what value they might bring until we fully understand what we have.
In the classic mode, which may ultimately be deprecated, but is still fully supported, there can be several separate cgroup hierarchies. Each hierarchy starts its life as a root cgroup, which initially holds all processes. This root node is created by mounting an instance of the «cgroup» virtual filesystem and all further modifications to the hierarchy happen through manipulations of this filesystem.
This is a very «organizational» way to manipulate a hierarchy: create a new group and find someone to fill it.
Here is a good article on the current status of v2 adoption (for example, viz. the Docker community):
The current adoption status of cgroup v2 in containers
Fedora 31 was released on October 29, 2019. This is the first major distro that comes with cgroup v2 (aka unified hierarchy) enabled by default, 5 years after it first appeared in Linux kernel 3.16 (Aug 3, 2014).
While the adoption of cgroup v2 is an inevitable step toward 2020s, most container implementations including Docker/Moby and Kubernetes still don’t support cgroup v2.
OK: to your question — «What is root CGROUP?»
All cgroups are hierarchical, so any cgroup can (and will) have a «root».
http://man7.org/linux/man-pages/man7/cgroups.7.html
Creating cgroups and moving processes
A cgroup filesystem initially contains a single root cgroup, ‘/’, which all processes belong to. A new cgroup is created by creating a directory in the cgroup filesystem:
This creates a new empty cgroup.
A process may be moved to this cgroup by writing its PID into the cgroup’s cgroup.procs file:
echo $$ > /sys/fs/cgroup/cpu/cg1/cgroup.procs Only one PID at a time should be written to this file.