Re: new reject msg from an arm64 buster install -- /usr/bin/tar executable?

Nathan Stratton Treadway <[email protected]> Tue, 3 Sep 2019 21:48:52 -0400
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <[email protected]>
On Tue, Sep 03, 2019 at 16:06:07 -0600, Charles Curley wrote:
> Based on these experiments, I suggest it will be easier for the
> installer to simply leave both lines enabled. I am not greatly worried
> about the security of leaving both enabled: if a bad guy can plop his
> own version of tar down in either of those two locations, you have
> other more immediate problems.
> 

Thanks for that exhaustive testing!  That certainly clarifies what edits
to that file will and won't solve the problem.


The annoying thing about having the package add both lines to the
amanda-security.conf file is that currently Debian doesn't do anything
special to that file, but simply uses the version that is generated by
the normal Amanda build process, and since all the path-related lines
are commented out the paths actually allowed are the ones that were
detected for the utilties in question at build time.

But as you discovered, as soon as you add one line for a particular
utility you have to add both (assuming you are trying to come up with a
file that will work on both merged and unmerged systems), and basically
the process of having the Debian package build script add the paths to
the file will involve not only the work of adding the code to make the
edits to that file, but also (as a side-effect) will decouple the
allowed-by-security.conf paths from the built-in default paths to the
executables (though admittedly that shouldn't actually be a big deal for
a Debian package).

Still, such a change may well be the most robust approach for getting
the Amanda packages to work transpentenly on both merged and unmerged
systems....

(Actually it's worth noting you need to add pairs of lines for both
runtar:gnutar_path= and amgtar:gnutar_path= .  Luckily star and bsdtar
are both already in /usr/bin, so they shouldn't need to have lines
added.)


In any case it does seem like it would be worth opening a Debian bug to
track this usrmerge v.s. Amanda issue.  (I just scanned the open bug
reports but didn't see any on this topic.)  Let me know if you want to do
that or if I should.



						Nathan

p.s. On the Buster systems you have installed from scratch, and thus
have the merge-onto-/usr in place, is the "usrmerge" package installed? 
The Release Notes mention that as a package the can be used to perform
the merge manually on systems that have been upgraded from pre-merge
releases, but I'm curious if the package gets installed during a fresh
install (i.e. when the system starts out merged).


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