On 12/20/23 06:02, Why 42? The lists account. wrote:
...
Reply-To:
Hi All,
A couple of questions ...
I have "ROOTBACKUP=1" in /etc/daily.local to replicate my root partition
as described in the FAQ (https://www.openbsd.org/faq/faq14.html#altroot)
I noticed after an update to a new snapshot via sysupgrade that the next
daily output email contains many many fsck "UNREF FILE" errors (See the
output included below). Is this expected, or is there some problem? Most
or all of the files seem to be owned by me (robb) so I'm thinking that
these errors may be related to files in /tmp ... Not sure why this occurs
though?
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.
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.
...
-r-xr-sr-x 1 root auth 21144 Nov 30 15:36:52 2023 /usr/bin/skeyinit
-r-xr-sr-x 1 root auth 21144 Dec 19 08:35:26 2023 /usr/bin/skeyinit
-r-xr-sr-x 1 root _sshagnt 440496 Nov 30 15:36:53 2023 /usr/bin/ssh-agent
-r-xr-sr-x 1 root _sshagnt 443856 Dec 19 08:35:26 2023 /usr/bin/ssh-agent
-r-sr-xr-x 1 root bin 19608 Nov 30 15:36:53 2023 /usr/bin/su
-r-sr-xr-x 1 root bin 19608 Dec 19 08:35:27 2023 /usr/bin/su
-r-xr-sr-x 1 root tty 17936 Nov 30 15:36:54 2023 /usr/bin/wall
-r-xr-sr-x 1 root tty 17936 Dec 19 08:35:28 2023 /usr/bin/wall
-r-xr-sr-x 1 root tty 14184 Nov 30 15:36:55 2023 /usr/bin/write
-r-xr-sr-x 1 root tty 14184 Dec 19 08:35:28 2023 /usr/bin/write
-r-xr-sr-x 4 root _token 21248 Nov 30 15:36:44 2023
/usr/libexec/auth/login_activ
-r-xr-sr-x 4 root _token 21248 Dec 19 08:35:18 2023
/usr/libexec/auth/login_activ
...
What actually changed then?
The files.
Surely many or all of these files had the same permission bits before the
upgrade?
Maybe these files now have diffent inode numbers, after the upgrade?
Why is each filename reported twice? Are these "old" and "new" values?
This isn't complaining about the EXISTENCE of setuid programs, it is advising
that setuid programs CHANGED from their last recorded version.
After all, if I manage to drop a new setuid program on your system, perhaps
naming it "ping" or "su", that would be bad, you might want to know about it.
Sure, dropping a setuid program that wasn't setuid before could be bad, but
replacing an existing one would be more sneaky.
You upgraded your machine, so you replaced a lot of setuid programs. And
yes, it shows date&time stamp and size of the old file and the new file.
Seeing something bump up or down a few bytes and matching the same date and
time stamp of other binaries after an upgrade is expected. Seeing that "su"
went from 20k to 70k might warrant investigation.
(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.)
Nick.
Thanks in advance for any feedback!
Cheers,
Robb.
Subject: mjoelnir daily output
...
OpenBSD 7.4-current (GENERIC.MP) #1535: Tue Dec 19 00:55:53 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
1:30AM up 7:20, 7 users, load averages: 0.62, 0.44, 0.40
Backing up root=/dev/rsd1a to /dev/rsd0a:
131071+0 records in
131071+0 records out
1073733632 bytes transferred in 10.509 secs (102169077 bytes/sec)
** /dev/rsd0a
** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=26656 (64 should be 32)
CORRECT? yes
INCORRECT BLOCK COUNT I=26688 (4128 should be 0)
CORRECT? yes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=26064 OWNER=robb MODE=100600
SIZE=4 MTIME=Dec 20 01:30 2023
CLEAR? yes
UNREF FILE I=26069 OWNER=robb MODE=10640
SIZE=0 MTIME=Dec 19 19:02 2023
CLEAR? yes
UNREF FILE I=26070 OWNER=robb MODE=10640
SIZE=0 MTIME=Dec 20 01:02 2023
CLEAR? yes
UNREF FILE I=26073 OWNER=robb MODE=100600
SIZE=28672 MTIME=Dec 20 01:30 2023
CLEAR? yes
...
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
6103 files, 101471 used, 412968 free (656 frags, 51539 blocks, 0.1%
fragmentation)
MARK FILE SYSTEM CLEAN? yes
***** FILE SYSTEM WAS MODIFIED *****
