What is the function of user group root? [duplicate]

Question

Possible Duplicate:
What does it mean to be in group 0?

I wanted to avoid using SSH root login to backup my remote server. Thus I set up a non-root user account on the server and place it under the root group thinking that it would possess the same privilege as a root user. But I soon realize that it cannot read files that are not grouped as root and files without the read permission for the group root. My question now is: does the group root serves any special purpose at all? And what is the common practice to backup a remote server (root or non-root)?

Answer 1

The "root" group doesn't serve a special purpose so much as it serves a general purpose - every file has to be owned by a user and a group, and "root" is there as sort of a default group for root user owned files that don't fall into other categories such as wheel (semi-old school) or bin. (This isn't purely factual, it's a heavy dose of personal opinion backed by experience.) For backups, as jordanm said, you will most likely need to use root user permissions.

Answer 2

Here is an article which already covers the group 0 part of your question.

Common Practice

Well I'm not sure if this is the best solution, but this is what I did, and I welcome comments/improvements/suggestions.

I recently set up a remote backup for a clients drupal website, my centralised backup server was accessing a remote server and pulling. I followed this principle.

• Created a user (on remote) which I wanted to use as admin, this user was permitted to login via ssh, but not using a password, only via a public/private key. (which you do need to keep safe and backed up at your admin location).
• Disabled root login via ssh, on the remote.
• Permitted my admin user to become root via sudo.

Note the user who would use this is me, and I don't sit on the backup server. So I used this to set up the backup below.

Now I can admin remote, root can't login only my special admin user and only via key certs.

• Created a backup user (the user who will perform the backups) on both remote and local, it wasn't the same username, I called her something a bit unusual (on remote), so even if the key was obtained, they would need to guess the remote user name too. The user is not priviledged and could not access the directories (or dump the database without password) on the remote.

• I permitted this User on the remote to run one command in /etc/sudoers myobscurebackupuser ALL=NOPASSWD: /usr/bin/rsync

• On my central backup server, under the user (who again is un-priviledged) I store the public/private key and the backup script which I want to run. Only this user can gain access to script/keys for reading (well apart from root).

• my backup was two steps

• Step 1 'ssh -i /path/to/key/file obscureuser@remote mysqldump [options] | gzip' | gunzip > local_dbdump.sql _Note The first half is excuted on remote (up to gzip), and second half runs locally.

• Step 2 rsync remote directory structure

The password and the database dump are not stored on the remote, they are passed in over the ssh connection. The db_dump is piped directly into gzip which sends it back over stdout. I pipe this through gunzip and direct stdout into local db dump file.

Answer 3

When I commonly have to do work as root, I do ssh commands like so:

# ssh [email protected] "hostname ; sudo -S some_backup_script.sh"

It allows logging of sudo activity, and the ability to use sudo permission to heavily restrict what the 'sudo' user logging in may do. It's excellent practice to have these sorts of tasks automated, with specific system users implemented for those specific functions; i.e. the backup user can use tar & gzip, and write to a /tmp directory, but denied access to cat, vim, etc (essentially commands that would allow it to print sensitive data.)