Re: Post (snap) update emails: fsck errors and (in)security output

On Wed, Dec 20, 2023 at 10:57:41AM -0500, Nick Holland wrote:
> the ROOTBACKUP process is making an image of a live file system; fsck
> grumblings ARE expected. It's just one of those things you aren't supposed
> to do (but I do it regularly, because normally, you can get away with it).
>
> Why the files it is grumbling about are owned by you ... that is a puzzle.
> Is your /tmp on a separate partition? If so, it shouldn't be being backed
> up by the ROOTBACKUP process. Same for "home" or any other file system you
> have access write to.

Interesting ... unexpectedly /tmp _is_ part of the root filesystem.

I have an entry in fstab to mount it as a seperate mfs filesystem but
that has failed for some reason. Probably then this is the reason that
the fsck errors are now occurring, being reported, and that I noticed
them.

Previously, when /tmp was transient, the root filesystem and the altroot
fsck process were not affected by content in /tmp.

Just tried the mount of /tmp manually from the command line at got:
mount_mfs: mmap: Cannot allocate memory

When I halved the size (memory) allocated (-s=2097152) it mounts
successfully:
mjoelnir:robb 20.12 19:50:02 # df -h /tmp
Filesystem Size Used Avail Capacity Mounted on
mfs:75507 1.9G 1.0K 1.8G 1% /tmp

Strange that it used to work. One day (!) I'll re-partition and allocate
a partition/slice of "real" storage to /tmp instead of using mfs.


> I also see this:
> > Backing up root=/dev/rsd1a to /dev/rsd0a:
> is sd1a actually your root, and sd0a actually your altroot?

> > Second question: Also after an upgrade, the "daily insecurity output"
> > contains a huge amount of setuid changes e.g.
> > ...
> > What actually changed then?
>
> The files.

Aha! - I see. I had in my head somehow understood "Setuid changes:" to
mean "changes to the setuid flags/bits of these files ...", not "these
files are suid and their content has changed". Maybe that is a better
description.

> (and yes, I have seen events where a major upgrade caused a lot of noise in
> a "something changed" file...which unfortunately hid something we needed to
> know about ALSO happened, and was dismissed as "part of the upgrade noise".
> This wasn't OpenBSD nor was it a "security event", but it did delay the
> detection and repair of a redundancy failure issue because one line was
> missed in a sea of thousands of lines of "yeah, that's expected" noise.)

It is a fair bit of noise in this case ... even more so with the
following "Block device changes" and the even longer "rpki" related
section.

Thanks!

Cheers,
Robb.