Re: bin/59990: /etc/security: first run mails megabytes of output

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 13 Feb 2026 05:38:23 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20260213053829.4F00585586%mail.netbsd.org@localhost>


  | - This won't show file additions on _upgrade_ from an earlier version
  |   of NetBSD whose /etc/security didn't create
  |   /var/backups/.firstdone.

That's fixable I think.

  | +if [ -f "$backup_dir/.firstdone" ]; then
  | +	firsttime=false
  | +else
  | +	firsttime=true
  | +	printf '' >>"$backup_dir/.firstdone"
  | +fi

One trivial comment there, you don't need to printf nothing to make
sure a file exists, just

	>>"$backup_dir/.firstdone"

is enough, but as I understand it, nothing ever gets put in the file,
it is always empty, so just ">" would work as well.

But if that were changed to

	FTD="$backup_dir/.firstdone"
	if [ -e "$FTD" ]
	then
		firsttime=false
	else
		>>"${FTD}"
		if [ -f "$backup_dir/etc/master.passwd.current" ]
		then
			firsttime=false
		else
			firsttime=true
		fi
	fi

then upgrades, that is, any time when /etc/security has been run
before, are handled just as if .firstdone was already existing,
as the one file that /etc/security *always* backs up is master.passwd
(there's no config anywhere I can see which allows that to be excluded).

Aside from style, and the missing meaningless printf nothing, two changes
there, the -f -> -e for the first test (all that matters is that the name
exists, no need to also confirm it is a regular file, linking something
else that exists to it (whatever file type) would work just as well, and
save an inode!

And only setting firsttime to true if there is no master.passwd backup
(that one has to be a regular file, or it isn't what it is pretending
to be.)



But this is still just half a solution to the problem, though it might
solve it (if it really needs solving) for many people.

The issue is that /etc/security is really just a wapper around a whole
host of independent (other than destination) backup & change notification
functions, and the multi-MB mail is just output from all of them together.

Some of them default off, and others on, but which are on/off is always
configurable.

Any time any of these switches from off -> on a large change list e-mail
can be generated (depending upon how much has changes while the option
was off).   How much of that ought be suppressed is likely to depend upon
the needs of the individual user, anything between none, and always suppress
all of it (ie: just backup stuff, don't send any mail about it, ever).

This is all not a simple issue.   Personally I'm not convinced it really
needs "fixing" at all.

kre