These legacy groups have existed since the early UNIX days, carrying forward into modern Linux distributions. The adm group (short for "administration") traditionally controlled access to various system logs in /var/log, while sys was more hardware-oriented for system devices.

Current distributions handle these groups differently:

# On Ubuntu 22.04:
$ ls -l /var/log/auth.log
-rw-r----- 1 syslog adm 12345 Jun 10 10:00 /var/log/auth.log

# On RHEL 9:
$ ls -l /var/log/secure
-rw-------. 1 root root 67890 Jun 10 10:01 /var/log/secure

Using these for superuser privileges isn't recommended because:

• adm often has read access to sensitive logs
• sys may have hardware device permissions
• Neither is consistently implemented across distros

For sudo access, create a dedicated group:

# Create custom admin group
sudo groupadd super

# Configure sudoers
echo "%super ALL=(ALL:ALL) ALL" | sudo tee -a /etc/sudoers

Modern systems use these groups for specific purposes:

# Checking group memberships
$ groups
user adm dialout cdrom sudo dip plugdev lxd

The adm group here grants log access while sudo handles privileges.

When implementing custom permissions:

# Better than using sys/adm:
sudo chown :developers /opt/dev-tools/
sudo chmod 2775 /opt/dev-tools/  # With setgid

Linux systems have long included two special groups: sys and adm. These groups serve specific purposes in system administration and access control. While they might seem similar at first glance, their roles are distinct and well-defined in Unix-like systems.

The adm group is traditionally used for system monitoring purposes. Members of this group typically have read access to various log files in /var/log and other system monitoring files.

# Example: Granting adm group access to log files
sudo chown root:adm /var/log/syslog
sudo chmod 640 /var/log/syslog

This allows system administrators to grant log viewing privileges without giving full root access. Common tools like logrotate and monitoring systems often require adm group membership.

The sys group is less commonly used today but historically provided access to system hardware and kernel-related files. In modern systems, its use has largely been replaced by more specific groups like disk, kmem, or tty.

# Historical example of sys group usage
sudo chown root:sys /dev/mem
sudo chmod 660 /dev/mem

While you could use these groups for super user privileges, it's not recommended. The wheel or sudo groups are more appropriate for this purpose. Here's why:

• These groups have well-defined historical purposes
• Using them differently could confuse other administrators
• Modern systems expect specific behavior from these groups

For sudo access, consider using the sudo group:

# Adding a user to the sudo group
sudo usermod -aG sudo username

For system administration tasks that don't require full root, create custom groups with specific permissions:

# Creating a custom admin group
sudo groupadd myadmin
sudo visudo
# Add line: %myadmin ALL=(ALL) ALL

When working with system groups:

1. Reserve adm for log access purposes
2. Avoid using sys unless maintaining legacy systems
3. Create custom groups for specific privilege sets
4. Document all group usage in your system documentation

Remember that while Linux gives you flexibility, following established conventions makes your systems more maintainable and easier to understand by other administrators.