6

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)?

1
  • 1
    If you are doing a full system backup, it will likely need to be done as root.
    – jordanm
    Feb 5, 2013 at 13:54

3 Answers 3

10

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.

3
  • I see... Thanks for explaining the reasoning behind :) Feb 5, 2013 at 14:17
  • New(ish) installation have a policy of giving each user their own group, so root gets group root too...
    – vonbrand
    Feb 5, 2013 at 14:49
  • 1
    vonbrand - true, but the root group predates user private group policies. There was a root group back when privileged users were put into the 'wheel' group and unprivileged were put into the 'staff' group. (Cripes I feel old now...)
    – John
    Feb 5, 2013 at 15:38
3

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.

2
  • Thanks for the details. But I am a bit confuse here as you are talking about the user settings on both the backup server as well as that of the remote server that is being backup. If my understanding is correct, you are using obscureuser at the remote server to do the backup instead of root and giving it the ability to run rsync as root by modifying the sudoer config. It looks workable, but I need to try out. +1 for the details. Feb 6, 2013 at 4:04
  • Yes, your summary is correct with the addition that the only way obscureuser can login to remote is via public/private key and I didn't clarify that remote is locked down so login via passwd is not permitted, only via public/private keys. There are only 2 key pairs onefor my adminuser and one for my obscure user, and only my adminuser can become root backup user can only run rsync.
    – X Tian
    Feb 6, 2013 at 11:33
1

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.)

1
  • Thanks, it looks similar to what X Tian has proposed. Yes, I am thinking about this because I am worried that my remote server will be severely compromised if my backup server having root and password free access is compromised. Feb 6, 2013 at 4:08

Not the answer you're looking for? Browse other questions tagged .