On Mon, May 27, 2019 at 00:59:53 -0400, Gene Heskett wrote:
> I figured the debs were using backup it was a good idea, just because it
> adds another layer of security by having to look up group to find backup
> is a member of the disk group. But theres so many places to change that
Your User/Group info, copied from your other message:
=====
root@coyote:amanda$ grep amanda /etc/passwd
amanda:x:1001:1001:xxxxxxxx,0,,:/home/amanda:/bin/bash
root@coyote:amanda$ grep amanda /etc/group
mail:x:8:gene,amanda
amanda:x:1001:backup
root@coyote:amanda$ grep backup /etc/group
disk:x:6:gene,backup
backup:x:34:
amanda:x:1001:backup
root@coyote:amanda$ grep backup /etc/passwd
backup:x:34:34:backup:/var/backups:/bin/bash
======
So... groups can't be members of groups in Unix; what you have right now
is the _user_ "backup" as a member of the "disk" group (which doesn't
matter at all to Amanda on your system)... and the user "amanda" is
_not_ a member of "disk", which is why you are having permission problems
trying to run the executables.
So, trying to make the "backup" group a member of the "disk" group
doesn't work... but you can achieve added security if you actually
avoiding the use of the "disk" group entirely. Amanda used to need to
be a member of that group in order to run the "dump" utility, but now
under Linux a setuid "rundump" program can used instead (and you don't
use "dump" anyway -- even more reason you don't need "disk" membership).
But if you do want to go down that road right now, you need to change
your gh.cf script so that it has "--with-group=backup" in place of the
current "--with-group=disk" line.
Your most recent error message (copied from your post in the other
thread) says:
======
ERROR: program /usr/local/libexec/amanda/ambind: wrong permission, must be
'rwsr-x---'
But that is what it almost is:
-rwsr-x--x 1 root disk 26840 May 26 21:59 /usr/local/libexec/amanda/ambind
It won't get past that point for anything if that final x isn't there
======
When you run the configure using --with-group=backup, that will cause
the Amanda install process to use "backup" as the group owner of those
binaries, thus allowing your Amanda user to execute them.
(Note that those setuid binaries MUST NOT BE executable by "other"; as
you can see, Amanda won't allow the programs to run if they are, because
otherwise any user on the system could execute them and obtain root
privileges.... But if you re-build Amanda now, it should install the
newly-build copies with all that corrected.)
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
