sa-compile error on ubuntu 14.04 LTS upgrade

Status changed to 'Confirmed' because the bug affects multiple users.

[SOLVED] (possibly I don't want to appear too arrogant on my first post :)

I updated my 12.04 to 14.04 with no problems and then recently I decided to increase my security with various tools like tripwire, ,tiger and lynis and one of the "recommendations" was to tighten up the security on gcc which I chmodded.

Another recommendation was to install libpam-tmpdir

About two weeks later I then purged my system of half installed packages and config files which because a lot of kernel files were involved I decided to reboot my system.

I then find out that amavis is not working suggesting running sa-update

Sep 22 19:02:54 rayzd amavis[17019]: Deleting db files __db.003,__db.002,snmp.db,nanny.db,__db.001 in /var/lib/amavis/db
Sep 22 19:02:54 rayzd amavis[17019]: Creating db in /var/lib/amavis/db/; BerkeleyDB 0.54, libdb 5.3
Sep 22 19:02:54 rayzd amavis[17019]: (!!)TROUBLE in pre_loop_hook: config: no rules were found! Do you need to run 'sa-update'?
Sep 22 19:02:54 rayzd amavis[17019]: (!)_DIE: Suicide () TROUBLE in pre_loop_hook: config: no rules were found! Do you need to run 'sa-update'?

(I am being verbose so that search engines pick up because there are many more than 4 users affected and there are multiple causes and initial suspects).

After running sa-update with no errors many times and still not getting a working email system, I researched clamav all the users and groups were fine, the socket for amavis and clamav matched, so I disabled spam assassin in /etc/amavis/conf.d/15-content_filter_mode *even though spam assassin was running fine and restarting and the process was clearly visible*. The mailqueue flushed and it was obvious there was an issue with spam assassin.

because the error message is obscure on a purge and then re-install

like the above or

/bin/sh: 1: cc: Permission denied
make: *** [body_0.o] Error 126
command 'make >>/tmp/.spamassassin

and doesn't explicitly point to gcc permissions then there are 100's of open forums and threads not just related to upgrades but to fresh installs. I believe that the upgrade process may have some legacy permission issues, certainly gcc needs to be checked for it's permissions and I noticed that sa-compile has a --sudo option, so the package scripts may be able to be altered (depending on a security risk assessment). With me, changing gcc's permissions back after having gone through the rest of the permission structure and then purging rebooting, removing libpam-tmp and changing login.def's umask back to 022 finally solved the problem.

Once again I apologise for the SEO protracted explanation and example of possible errors this bug has caused but there are many versions affecting more than 4 people.

Been running, testing, re-installing and rebooting a lot of times since my post above.

I've noted that in

/etc/cron.daily/spamassassin

there is umask 022 to updated the spam assassin rules, and consistently "the system" will fail to install or fall over if login.defs is changed to 027 on reboot or re-installation. Interestingly I have it now where everything is owned but root in the spam assassin folder

ls -l spamassassin/ -a
total 60
drwxr-xr-x 4 root root 4096 Sep 26 07:12 .
drwxr-xr-x 108 root root 12288 Sep 29 07:54 ..
-rw-r--r-- 1 root root 939 Jan 28 2015 65_debian.cf
-rw-r--r-- 1 root root 1289 Jan 28 2015 init.pre
-rw-r--r-- 1 root root 2213 Jan 28 2015 local.cf
-rw-r--r-- 1 root root 118 Jan 28 2015 sa-compile.pre
drwxr-xr-x 2 root root 4096 Sep 22 18:15 sa-update-hooks.d
drwx------ 2 root root 4096 Sep 26 07:12 sa-update-keys
-rw-r--r-- 1 root root 2524 Jan 28 2015 v310.pre
-rw-r--r-- 1 root root 1194 Jan 28 2015 v312.pre
-rw-r--r-- 1 root root 2416 Jan 28 2015 v320.pre
-rw-r--r-- 1 root root 1237 Jan 28 2015 v330.pre
-rw-r--r-- 1 root root 1020 Jan 28 2015 v340.pre

from a purge and install and everything works as long as /etc/login.defs is set to 022, so it looks like the upgrade/ install problems solely come out of an sa-compile and possibly sa-update not having a umask 022 set in the dpkg scripts with no permission checks on /var/lib/spamassassin/3.004000 and /var/lib/spamassassin/compiled from legacy installed (mine being owned "now" by debian-spamd).

The cron job script provides a good guide as to previous permission issues having been identified and fixed.

Thank you for taking the time to report this bug and helping to make Ubuntu better.

It sounds like this happens after local changes involving hardening, then? Could you please narrow it down to a specific series of steps after which spamassassin/sa-compile would reasonably be expected to work, but doesn't? Otherwise it isn't clear that this isn't just a configuration change after which spamassassin couldn't be expected to work anyway.

Once done, please change the bug status back to New. Thanks!

[Expired for spamassassin (Ubuntu) because there has been no activity for 60 days.]