On Fri, 17 May 2019 19:53:11 -0400
Nathan Stratton Treadway <[email protected]> wrote:
> On Thu, May 16, 2019 at 16:52:57 -0600, Charles Curley wrote:
> > * amanda seems to be creating a lot of stuff as amandabackup:disk.
> > Is that right? Shouldn't it be creating stuff as
> > amandabackup:amandabackup?
>
> Before amanda packages are installed, I believe a Debian/Ubuntu system
> starts out with no users in the "disk" group, and the only use of that
> group is for ownership of block device files (e.g.
> # ls -l /dev/sda*
> brw-rw---- 1 root disk 8, 0 May 15 15:17 /dev/sda
> brw-rw---- 1 root disk 8, 1 May 15 15:17 /dev/sda1
> brw-rw---- 1 root disk 8, 2 May 15 15:17 /dev/sda2
> brw-rw---- 1 root disk 8, 3 May 15 15:17 /dev/sda3
> )
A quick look ("find / -group disk") at an Ubuntu 18.04 system supports
that hypothesis. It has no users in group disk, and everything owned by
group disk is in /dev, and is owned by root:disk.
>
> Pages such as
> https://wiki.debian.org/SystemGroups
> document the purpose of the "disk" group as "Raw access to disks."...
> (and in fact warn that putting a user in that group is "Mostly
> equivalent to root access").
That is my recollection also.
>
> As far as I understand, Amanda needs to use that "disk"-group
> permission when using the the "dump" backup utility, because "dump"
> directly reads the source data via the filesystem's block device
> file. Other backup tools (e.g. tar) do not directly access the block
> device and don't rely on the "disk" group permissions.
>
> On a couple systems I have here running the official Debian Amanda 3.5
> packages (and on which I do _not_ use the "dump" program), the Amanda
> packages don't seem to create any files with "disk"-group ownership.
That is what I see on my server (which is also a client), and one
client. Both run amanda 1:3.3.9-5.
>
> However, the
> http://wiki.zmanda.com/index.php/Amanda_packages_from_Zmanda_downloads_page
> page only mentions the "disk" group, and the preinst script uses the
> "disk" group when creating the amandabackup user, so it's not too
> surprising that files created by Zmanda-packaged Amanda programs end
> up with "disk" group ownership....
Well, methinks they shouldn't be in group disk, but in group
amandabackup. I don't believe in giving an executable any more
permissions than it absolutely must have to do its job, and I don't see
that any amanda program needs to be in group disk. Here's the list of
executables I've found to be in group disk:
/usr/lib/x86_64-linux-gnu/amanda/killpgrp
/usr/lib/x86_64-linux-gnu/amanda/runtar
/usr/lib/x86_64-linux-gnu/amanda/application/amgtar
/usr/lib/x86_64-linux-gnu/amanda/application/amstar
/usr/lib/x86_64-linux-gnu/amanda/rundump
/usr/lib/x86_64-linux-gnu/amanda/calcsize
/usr/lib/x86_64-linux-gnu/amanda/ambind
>
> This does feel like it goes against the usual Debian approach, though
> I guess having files owned by "disk" isn't really a security risk
> (given that presumably only the "amandabackup" user is a member of
> that group anyway)...
Don't bet on it. Some admins will add users to group disk in order to
give them direct access to hardware. Although I don't know how having
executables owned by that group can be a security risk, I don't like it.
>
>
> > An I creating the user correctly?
> >
> > adduser --disabled-password amandabackup
> > adduser amandabackup disk
>
> What does "grep amandabackup /etc/passwd /etc/group" show?
>
> If I am understanding the source repo correctly, the amanda*.preinst
> scripts (for the Zmanda packages) include logic to create the
> amandabackup user with a hard-coded UID of "63998" (and a
> primary/"initial login" group of "disk"). I guess the scripts won't
> (re-)create or update the user if you have previously created it, but
> I am curious to see which definition is actually in effect on your
> system.
root@amanda:~# grep amandabackup /etc/passwd /etc/group
/etc/passwd:amandabackup:x:1001:1001::/home/amandabackup:/bin/bash
/etc/group:disk:x:6:amandabackup
/etc/group:tape:x:26:amandabackup
/etc/group:amandabackup:x:1001:amandabackup
root@amanda:~#
I had to create the user in order to build the debian packages, which
strikes me as an unnecessary requirement.
Debian has the user "nobody":
root@amanda:~# grep nobody /etc/passwd /etc/group
/etc/passwd:nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
root@amanda:~#
Back in the late Pliocene I had problems with NFS, and using that gid
and uid turned out to be useful for searching and destroying some of
the debris. But I don't see that amanda needs an oddball uid or gid. Do
you?
--
"When we talk of civilization, we are too apt to limit the meaning of
the word to its mere embellishments, such as arts and sciences; but
the true distinction between it and barbarism is, that the one
presents a state of society under the protection of just and
well-administered law, and the other is left to the chance government
of brute force."
- The Rev. James White, Eighteen Christian Centuries, 1889
Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB
https://charlescurley.com
