Amanda-Users

Re: amcheck/amdump fails (sometimes) to amanda client

2004-05-20 18:00:18
Subject: Re: amcheck/amdump fails (sometimes) to amanda client
From: Eric Siegerman <erics AT telepres DOT com>
To: amanda-users AT amanda DOT org
Date: Thu, 20 May 2004 17:57:46 -0400
On Thu, May 20, 2004 at 04:47:32PM -0400, Gene Heskett wrote:
> On Thursday 20 May 2004 14:10, Steven Schoch wrote:
> > The client (named "marge") is
> > running FreeBSD 4.7, running amanda 2.4.4p2 compiled from source
> >
> >./configure --without-server --with-group=amanda --with-user=amanda
> >--with-amandahosts
> 
> This is the wrong group

Agreed.  For our FreeBSD systems it's group "operator".


> the group may be bin, backup or disk, but it 
> should have essentially root rights to the system.

I strongly disagree!  Maybe "backup" or "disk", depending on the
box, but NOT "bin" (I posted on this a couple of days ago), and
NOT "essentially root rights".

The only special privilege the Amanda client needs is to read
data off the disks.  Precisely what privilege that consists of
depends on the circumstances:
  - For gtar, you need root.  More specifically, gtar itself
    needs root, but the rest of the Amanda process tree doesn't.
    Amanda provides the runtar wrapper program, which is
    installed setuid root, to give gtar the privilege it needs.
    Thus, Amanda can run under any user+group combination at all.

    Safety suggests creating a user and group specifically for
    Amanda, especially because that's the best way to keep
    ordinary users from being able to use runtar for their own
    nefarious purposes (this works because runtar is installed
    as:
        -rwsr-x---    1 root     XXX         36615 Jun 25  2003 runtar
    where XXX is the group specified to "--with-group", i.e.
    without world execute permission).

    On the system where we use gtar, I made the obvious choice:
    "--with-group=amanda".

  - On some systems, dump (or the local equivalent -- ufsdump,
    vfxdump, or whatever) also needs root.  But again, Amanda
    provides a setuid-root wrapper, rundump, to accomplish that,
    so all of the above applies to this case too.  (rundump is
    only installed on systems whose dump requires it, or you can
    force the issue by passing "--with-rundump" to configure.)

  - On other systems, including FreeBSD, all dump needs is read
    (but NOT write) permission on the disk-device special files.
    One of these, chosen at random from one of our FreeBSD boxen,
    looks like this:
        crw-r-----  2 root  operator  116,  27 Apr 28  2003 /dev/rad3d
    Thus, building Amanda with "--with-group=operator" is all
    that's needed.  On this box, the "operator" group doesn't
    have access to very much else at all.  If it had, I'd
    probably have created a new group for Amanda and chgrp'ed the
    special files in question.

    On our Solaris boxes, the group with read-only access to the
    disk special files is "sys".  So that's what I built Amanda
    with for Solaris.  To be honest, I no longer remember whether
    either Solaris or FreeBSD sets up disk-device special files
    this way "out of the box", or whether I did it myself.


> A gid <=10 is 
> desireable.

This doesn't seem relevent one way or the other.  No gid's have
any special privilege as far as the kernel is concerned.  (And
even for uid's, <=10 has no significance -- only ==0 is magic.)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        erics AT telepres DOT com
|  |  /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
        - Patrick Lenneau