On Sat, May 18, 2019 at 13:49:07 -0600, Charles Curley wrote:
> On Fri, 17 May 2019 19:53:11 -0400
> Nathan Stratton Treadway <[email protected]> wrote:
>
> 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
For comparison, in the official Debian package, these programs are owned
by "backup", but they are SUID root and only executable by group, so the
point of the group ownership seems to be to limit the ability to run the
(SUID) binary:
# find /usr/lib -group backup -ls
899 12 -rwsr-xr-- 1 root backup 10232 Nov 12 2018
/usr/lib/amanda/rundump
[...]
1108 12 -rwsr-x--- 1 root backup 10232 Nov 12 2018
/usr/lib/amanda/ambind
393250 40 -rwsr-xr-- 1 root backup 40224 Nov 12 2018
/usr/lib/amanda/application/amstar
393231 52 -rwsr-xr-- 1 root backup 53008 Nov 12 2018
/usr/lib/amanda/application/amgtar
821 20 -rwsr-xr-- 1 root backup 18424 Nov 12 2018
/usr/lib/amanda/calcsize
[...]
975 16 -rwsr-xr-- 1 root backup 14328 Nov 12 2018
/usr/lib/amanda/runtar
868 12 -rwsr-xr-- 1 root backup 10232 Nov 12 2018
/usr/lib/amanda/killpgrp
Hmmm... note here the SUID binary "rundump". Looking at that program
and the other programs that reference it, I believe that Amanda (at
least in the default configuration) no longer actually needs to use the
"disk" group access at all -- instead, it seems that "dump" is called
with root permissions via the "rundump" program (which mirrors how
"runtar" invokes the tar program with root permissions).
> >
> > 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:~#
Okay, that's the user you created. I guess the lesson is that the user
definition on the system where the package is built has to match the
system where the package is installed. In your case you created the
user prior to building the package and left it in place when installing
the package, so the preinst script did not need to create the user. On
the other hand, if you were to use the .deb files from the Zmanda
website (rather than building your own), the amandabackup user would not
exist, and the preinst script would have created it, using the
hard-coded UID so that it matched the user used to build the .deb
files... (And if you tried to install the .deb files you built on
another Debian system which did not already have an amandabackup user
with UID 1001, confusion would result....)
> I had to create the user in order to build the debian packages, which
> strikes me as an unnecessary requirement.
Because .deb files store file/group ownership information for the files
contained in the package (and for Amanda you do want at least some
directories to be owned by the Amanda user and some binaries to be owned
by the Amanda group), I think the "Amanda user" does need to exist at
build time.
The official Debian packages work around this problem by using the
"backup" user (and "backup" group); those are part of the basic
Debian installation, neither building nor installing the Amanda .deb
files needs to fuss with creating the Unix user (or group)
Clearly the Zmanda .deb files are built to match the Zmanda-provided
packages for other operating systems... but I don't know how much of the
current ownership/permissions/security setup is still actually necessary
and how much is left over from when the Debian packaging was first
created. (I don't follow the Zmanda package closely, but it looks like
the user/group stuff is mostly unchanged since the packaging files were
first introduced a decade ago...)
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [email protected] - 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
