NetBSD Problem Report #59990

From www@netbsd.org  Tue Feb 10 04:17:46 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id D7A391A923D
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 10 Feb 2026 04:17:45 +0000 (UTC)
Message-Id: <20260210041745.14A721A923E@mollari.NetBSD.org>
Date: Tue, 10 Feb 2026 04:17:45 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: /etc/security: first run mails megabytes of output
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         59990
>Category:       bin
>Synopsis:       /etc/security: first run mails megabytes of output
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 10 04:20:00 +0000 2026
>Last-Modified:  Sun Feb 15 20:15:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
The NetBSecuriD Foundafile, Inc.
>Environment:
>Description:
The first time /etc/security runs, it copies essentially all of /etc (and /root and a copy of `ls -l /dev' and various other things) into the mail.

This is not particularly useful, especially parts like the 3 MB /etc/services.  Ideally, it would (quietly) archive the original installation, and only report changes from that in the mail.
>How-To-Repeat:
install NetBSD in a way that the daily insecurity report goes somewhere
>Fix:
Yes, please!

>Audit-Trail:
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Wed, 11 Feb 2026 03:01:38 +0300

 > The first time /etc/security runs, it copies essentially all of /etc
 > (and /root and a copy of `ls -l /dev' and various other things) into
 > the mail.

 Yes, please, indeed.

 > This is not particularly useful, especially parts like the 3 MB
 > /etc/services.  Ideally, it would (quietly) archive the original
 > installation, and only report changes from that in the mail.

 It already does the backup part and the diff part, it's the first run,
 when the baseline is empty, that is the problem.

 -uwe

From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: uwe@NetBSD.org
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Fri, 13 Feb 2026 05:38:23 +0000

 This is a multi-part message in MIME format.
 --=_17Wymd7lPaKOmlAiVMiz9N/EY5eA0fm1

 The attached patch fixes this.  Some caveats; could stand review and
 additional thought by other eyeballs than mine.

 --=_17Wymd7lPaKOmlAiVMiz9N/EY5eA0fm1
 Content-Type: text/plain; charset="ISO-8859-1"; name="pr59990-securityfirstrun"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename="pr59990-securityfirstrun.patch"

 # HG changeset patch
 # User Taylor R Campbell <riastradh@NetBSD.org>
 # Date 1770960370 0
 #      Fri Feb 13 05:26:10 2026 +0000
 # Branch trunk
 # Node ID 1b592182187334d0db950753ee819bfab9e74ed8
 # Parent  b521b79a1472b92939551ff546413543818a32a9
 # EXP-Topic riastradh-pr59990-securityfirstrun
 /etc/security: Don't show `additions' on first run.

 It is not helpful to send a multi-megabyte message with an entire
 copy of /etc, ls -l /dev, and whatever else to the operator the first
 run of /etc/security.  Instead, additions should be reported when
 they are _changes_ from the stock installation.

 Mechanism: If there's no /var/backups/.firstdone, we create it and
 skip printing file additions into the report.

 Caveats:

 - This does leave a window between the time of installation and the
   time of the first daily cron job.

   =3D> If that's important to avoid, you could avoid it by just running
      /etc/security once immediately after installation.

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

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

 diff -r b521b79a1472 -r 1b5921821873 etc/security
 --- a/etc/security	Fri Nov 28 15:15:34 2025 +0000
 +++ b/etc/security	Fri Feb 13 05:26:10 2026 +0000
 @@ -44,6 +44,13 @@ if [ ! -d "$work_dir" ]; then
  	mkdir -p "$work_dir"
  fi
 =20
 +if [ -f "$backup_dir/.firstdone" ]; then
 +	firsttime=3Dfalse
 +else
 +	firsttime=3Dtrue
 +	printf '' >>"$backup_dir/.firstdone"
 +fi
 +
  SECUREDIR=3D$(mktemp -d -t _securedir) || exit 1
 =20
  trap "/bin/rm -rf $SECUREDIR ; exit 0" EXIT INT QUIT PIPE
 @@ -161,11 +168,13 @@ backup_and_diff()
  				backup_file update $_file $CUR $BACK
  			fi
  		else
 -			printf "\n=3D=3D=3D=3D=3D=3D\n%s added\n=3D=3D=3D=3D=3D=3D\n" $_file
 -			if [ "$_printdiff" -ne 0 ]; then
 -				diff ${diff_options} /dev/null $_file
 -			else
 -				echo "[changes omitted]"
 +			if ! $firsttime; then
 +				printf "\n=3D=3D=3D=3D=3D=3D\n%s added\n=3D=3D=3D=3D=3D=3D\n" $_file
 +				if [ "$_printdiff" -ne 0 ]; then
 +					diff ${diff_options} /dev/null $_file
 +				else
 +					echo "[changes omitted]"
 +				fi
  			fi
  			backup_file add $_file $CUR $BACK
  		fi
 @@ -855,9 +864,11 @@ if checkyesno check_devices; then
  				backup_file update $TMP1 $CUR $BACK
  			fi
  		else
 -			printf "Device additions:\n" >> $ERR
 -			column -t $TMP1 >> $ERR
 -			printf "\n" >> $ERR
 +			if ! $firsttime; then
 +				printf "Device additions:\n" >> $ERR
 +				column -t $TMP1 >> $ERR
 +				printf "\n" >> $ERR
 +			fi
  			backup_file add $TMP1 $CUR $BACK >> $ERR
  		fi
  	fi

 --=_17Wymd7lPaKOmlAiVMiz9N/EY5eA0fm1--

From: Robert Elz <kre@munnari.OZ.AU>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org, uwe@NetBSD.org
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Fri, 13 Feb 2026 23:35:25 +0700

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


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

From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sat, 14 Feb 2026 01:45:19 +0300

 On Fri, Feb 13, 2026 at 05:38:23 +0000, Taylor R Campbell wrote:

 >   => If that's important to avoid, you could avoid it by just running
 >      /etc/security once immediately after installation.

 I try to remember and do that before I make _any_ customizations so
 that the r1.1 of the backup is as close to the pristine contents of
 /etc as possible.  Run security backup step from sysinst?

 -uwe

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sat, 14 Feb 2026 09:21:50 +0100

 On Fri, Feb 13, 2026 at 10:50:02PM +0000, Valery Ushakov via gnats wrote:
 >  >   => If that's important to avoid, you could avoid it by just running
 >  >      /etc/security once immediately after installation.
 >  
 >  I try to remember and do that before I make _any_ customizations so
 >  that the r1.1 of the backup is as close to the pristine contents of
 >  /etc as possible.  Run security backup step from sysinst?

 That would make sense, best before we enter the configuration step and
 start adding users or configure ssh, but only e.g. if no master.passwd
 backup is found so far (in sysinst this code path is shared beween new
 installs and upgrades, and you can invoke that stage manually).

 This doesn't help typical image installs (often used for virtual
 machines), where we just resize the filesystem and continue running the
 install medium. But we could add a rc.d script that runs very late
 and checks the same condition as sysinst would.

 Martin

From: "Greg A. Woods" <woods@planix.ca>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sat, 14 Feb 2026 13:58:02 -0800

 --pgp-sign-Multipart_Sat_Feb_14_13:57:50_2026-1
 Content-Type: text/plain; charset=US-ASCII

 At Fri, 13 Feb 2026 22:50:02 +0000 (UTC), "Valery Ushakov via gnats" <gnats-admin@NetBSD.org> wrote:
 Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
 >
 >  On Fri, Feb 13, 2026 at 05:38:23 +0000, Taylor R Campbell wrote:
 >
 >  >   => If that's important to avoid, you could avoid it by just running
 >  >      /etc/security once immediately after installation.
 >
 >  I try to remember and do that before I make _any_ customizations so
 >  that the r1.1 of the backup is as close to the pristine contents of
 >  /etc as possible.  Run security backup step from sysinst?

 I would definitely vote for having sysinst do the first run!

 --
 					Greg A. Woods <gwoods@acm.org>

 Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

 --pgp-sign-Multipart_Sat_Feb_14_13:57:50_2026-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Content-Description: OpenPGP Digital Signature

 -----BEGIN PGP SIGNATURE-----

 iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCaZDv4QAKCRBmfXG3eL/0
 f4zHAKCfLhL2HkJcL2lK/3fmUAv3srZrwACfTxvf/fCsyuA+tKRhERQeddOs6Hw=
 =gkPr
 -----END PGP SIGNATURE-----

 --pgp-sign-Multipart_Sat_Feb_14_13:57:50_2026-1--

From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sun, 15 Feb 2026 14:55:28 +0300

 On Sat, Feb 14, 2026 at 08:25:02 +0000, Martin Husemann via gnats wrote:

 >  This doesn't help typical image installs (often used for virtual
 >  machines), where we just resize the filesystem and continue running
 >  the install medium.

 But we can just prepopulate /var/backups on such images when creating
 them.

 -uwe

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Valery Ushakov <uwe@stderr.spb.ru>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sun, 15 Feb 2026 14:34:21 +0000

 > Date: Sun, 15 Feb 2026 14:55:28 +0300
 > From: Valery Ushakov <uwe@stderr.spb.ru>
 > 
 > On Sat, Feb 14, 2026 at 08:25:02 +0000, Martin Husemann via gnats wrote:
 > 
 > >  This doesn't help typical image installs (often used for virtual
 > >  machines), where we just resize the filesystem and continue running
 > >  the install medium.
 > 
 > But we can just prepopulate /var/backups on such images when creating
 > them.

 We could try that, but it's not easy.

 We'd have to either duplicate all the logic in /etc/security or factor
 it out into a common place, and make it operate relative to a destdir.
 And we'd have to model the listing of devices and suid/sgid files via
 mtree(8) -- and find some way to model the disklabels and MBRs too
 (and GPTs if we did that).

 So perhaps a simpler approach -- and what I'm trying right now for the
 present purpose -- is an rc script that just does:

 	# Make sure /etc/security has saved a backup of everything.
 	if ! [ -s /var/backups/etc/master.passwd.current ]; then
 		/etc/security >/dev/null
 	fi

 (master.passwd is the one file that is unconditionally always backed
 up, hard-coded in /etc/security.)

From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sun, 15 Feb 2026 18:49:11 +0300

 On Sun, Feb 15, 2026 at 14:34:21 +0000, Taylor R Campbell wrote:

 > And we'd have to model the listing of devices and suid/sgid files via
 > mtree(8) -- and find some way to model the disklabels and MBRs too
 > (and GPTs if we did that).

 It doesn't have to be perfect.  Just pre-creating the baseline
 "backups" for the /etc and /root dot-files is already an
 improvement... and saves time on the first boot for slower machines
 (spare a thought for a diskless Jornada with NFS root over 10MB PCMCIA
 card, or slower SD cards in arm gizmos).

 For anything else, do we really need to send the initial diff against
 /dev/null?  New etc files are "interesting".  The initial list of
 devices probably not so much.  Just don't emit the diff that is
 against non-existing baseline?


 > So perhaps a simpler approach -- and what I'm trying right now for the
 > present purpose -- is an rc script that just does:
 > 
 > 	# Make sure /etc/security has saved a backup of everything.
 > 	if ! [ -s /var/backups/etc/master.passwd.current ]; then
 > 		/etc/security >/dev/null
 > 	fi
 > 
 > (master.passwd is the one file that is unconditionally always backed
 > up, hard-coded in /etc/security.)

 I guess that's not _too_ bad, as long as it doesn't take a week on
 sun2... :) Pre-creating the "backups" that we can precreate will
 probably speed it up too.


 -uwe

From: Taylor R Campbell <riastradh@NetBSD.org>
To: Valery Ushakov <uwe@stderr.spb.ru>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sun, 15 Feb 2026 19:17:22 +0000

 > Date: Sun, 15 Feb 2026 18:49:11 +0300
 > From: Valery Ushakov <uwe@stderr.spb.ru>
 > 
 > On Sun, Feb 15, 2026 at 14:34:21 +0000, Taylor R Campbell wrote:
 > 
 > > And we'd have to model the listing of devices and suid/sgid files via
 > > mtree(8) -- and find some way to model the disklabels and MBRs too
 > > (and GPTs if we did that).
 > 
 > It doesn't have to be perfect.  Just pre-creating the baseline
 > "backups" for the /etc and /root dot-files is already an
 > improvement... and saves time on the first boot for slower machines
 > (spare a thought for a diskless Jornada with NFS root over 10MB PCMCIA
 > card, or slower SD cards in arm gizmos).

 There's another complication: we would need to either toolify RCS (or
 at least ci(1)), or hackily generate the initial ,v file another way.

 > > So perhaps a simpler approach -- and what I'm trying right now for the
 > > present purpose -- is an rc script that just does:
 > > 
 > > 	# Make sure /etc/security has saved a backup of everything.
 > > 	if ! [ -s /var/backups/etc/master.passwd.current ]; then
 > > 		/etc/security >/dev/null
 > > 	fi
 > > 
 > > (master.passwd is the one file that is unconditionally always backed
 > > up, hard-coded in /etc/security.)
 > 
 > I guess that's not _too_ bad, as long as it doesn't take a week on
 > sun2... :) Pre-creating the "backups" that we can precreate will
 > probably speed it up too.

 Well, if it takes a week, the daily insecurity report will be in
 trouble too!

 Do we even have any mechanism for preventing a long-running /etc/daily
 or /etc/security from overlapping with the next run?  I don't see any
 obvious lock files or collision detection.

From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/59990: /etc/security: first run mails megabytes of output
Date: Sun, 15 Feb 2026 23:13:16 +0300

 On Sun, Feb 15, 2026 at 19:17:22 +0000, Taylor R Campbell wrote:

 > Do we even have any mechanism for preventing a long-running
 > /etc/daily or /etc/security from overlapping with the next run?

 We don't.  I don't remember the details, but a few years ago I had a
 failure mode that would make daily/security stuck (pmtu mess or
 something that would make fetching pkgsrc vulnerabilities never
 complete, IIRC) and so there would be several daily jobs happily doing
 nothing in parallel.

 -uwe

Home	PR Database Search