[gentoo-dev] migration of "default" folders and fixups of exitsing installed folders

[Jaco Kroon]

Hi,

In some ways not unlike the discussion around users being installed and
later updated ... so I'm guessing I'm going to have varied opinions and
feedback on this potentially.  Ironically, asterisk was one of those
users that had it's home folder (correctly) adjusted from
/var/lib/asterisk to /dev/null.

In this case:

1.  I would like to update where asterisk stores astdb (partially for
security reasons);
2.  And on existing installs, /var/{lib,spool}/asterisk may well have
what I consider to be insecure ownership and permissions.

I have some ideas about the former (below), the latter I have no ideas
about.

There used to be a "fix permissions" script in the asterisk init script
(that was considered to be a security vulnerability, and was removed,
not to mention that it didn't exactly set same to be as secure as it can
be, and there are legitimate reasons to not use the strictest possible
permissions on *some* of the folders beneath both these locations, but
most of them should be root:root, and root:asterisk in specific cases,
and only in a very few cases asterisk:root possibly).  Suggestions on
fixing these permissions if (and only if) they were unmodified by the
user.  And making sure the user is aware of these.

Re the former:  https://bugs.gentoo.org/761442 relates.

History:

asterisk project simply used to install everything as
asterisk:asterisk.  Config files, resource files, everything,
irrespective of whether or not runtime required write access or not (I
think the exception was the binary and module libraries).  This was from
upstream project.  Myself and a few others started upsetting the apple
cart with things like "why are audio files installed writeable by
asterisk?".  Upstream caught onto this and started fixing some things up
(I don't have references, but things have definitely changed).

Bottom line:

/var/lib/asterisk used to be installed as asterisk:root, 750.

It's now being installed as root:root 755 (I'd prefer root:asterisk 750
personally)

There are only two pieces of information inside /var/lib/asterisk that
needs to (potentially) be writeable by asterisk.

1.  astdb.sqlite3 (and it's -journal file which doesn't always exist)
2. coredump/ folder (only required if configured to core dump).

The latter is a non-issue since this folder is specifically installed
asterisk:root.

astdb is a problem, since in order to create the -journal file I need to
give write access to asterisk to the folder (which I'd prefer to not do).

Disclaimer:  Depending on what you're doing there might be motivation to
have a few extra specific locations writeable by asterisk beneath
/var/lib/asterisk (we do have that, but this should be an explicit
action by the administrator in my opinion, if I could I'd install
everything there as root:root - which is just about the case currently).

What I'd rather prefer to do is to create an additional asterisk:root
astdb folder beneath /var/lib/asterisk and have asterisk use that for
astdb.  This is easy enough to configure, and even to update the default
config files.

But what to do with existing installations?  A person would need to "opt
in" to this change by way of etc-update I guess (I'll keep a ::gentoo
patch to basically enable the [directories] section, and to set astdbdir
= /var/lib/asterisk/astdb by default).  But unless the person modified
asterisk.conf (entirely possible, generally you don't need to customize
this config file) that will auto update this file.  And on next asterisk
restart the person will lose his existing astdb.sqlite3 file.

So ... I could check for /var/lib/asterisk/astdb.sqlite3 in init script
... but if the user opted out of te config update ... moving the file
here (which is a bad idea in my opinion anyway) is a terrible idea.  Not
moving the file will simply result in asterisk creating a new
astdb.sqlite3 file in the new folder - which carries risk if (and only
if) the user cares about persistence in astdb (which my systems
specifically don't, but some others do).  By *default* nothing that
asterisk itself stores into astdb requires persistence (but it is
preferred, for example, if I REGISTER to asterisk, it is nice that it
doesn't "forget" my registration over restarts or even reboots).

At this point I'm inclined to put a big ewarn in the updated ebuilds in
pkg_pretend, warning of this default config change (if you're updating
from an older asterisk where the default was /var/lib/asterisk),
installing the new folder and moving on with my life.  Since all my
installs already has /var/lib/asterisk/astdb on a ramdisk, I'm not
affected, but I really would prefer to not catch users off guard.

Currently new installs of asterisk is semi broken by default, easy to
fix either by chown asterisk:root /var/lib/asterisk, or by install -d
-oasterisk -groot -m0750 /var/lib/asterisk/astdb and simple (2 lines)
config change to /etc/asterisk/asterisk.conf.

Just looking for other possible approaches here.

Migration is also easy enough:  update config for new location, stop
asterisk, mv the sqlite3 file, start asterisk.

Kind Regards,
Jaco