Re: ***UNCHECKED*** Re: Post (snap) update emails: fsck errors and (in)security output
On Thu, Dec 21, 2023 at 08:20:37AM -0300, Crystal Kolipe wrote: > > login.conf used to allow unlimited datasize for the 'daemon' class. That was > > changed to cap at 4G > > Actually the value is an architecture dependent setting. > > On amd64 it is indeed 4G, but typically 1024 Mb on the smaller archs which > until recently, (post 7.4), included i386, which has now been increased to > 1500 Mb. Shouldn't it vary according to the amount of RAM available on the system? Or is the backing store (swap) more relevant? Anyway ... > BTW, we already had this exact same discussion with Robb on the list back in > February: > > https://marc.info/?l=openbsd-misc=167561903118994 > > So when I asked why he didn't just bump the value, it was indeed a question > and not a suggestion to just do it. Oh right :-) Seems like I was fat and happy in February with "-s=4194304" in fstab and "df -h /tmp" returning 1.8G available. I don't know why or when it stopped working in the meantime. Maybe daily should report failed mounts? I mean, normally, something like that is hard to miss, but with /tmp it's not so obvious. Just a thought. I guess I tend to avoid modifying login.conf to avoid having to fix issues reported by sysmerge after an upgrade. But in reality those don't occur that often and I'm just being overly sensitive. Right now login.conf contains: > daemon:\ >:ignorenologin:\ >:datasize=4096M:\ >:maxproc=infinity:\ >:openfiles-max=1024:\ >:openfiles-cur=128:\ >:stacksize-cur=8M:\ >:tc=default: > ... I was just able to mfs_mount 2GB on the command line: > mjoelnir:robb 28.12 17:13:17 # mkdir /tmptmp > mjoelnir:robb 28.12 17:13:25 # df -h /tmptmp > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd1a 1005M250M704M27%/ > mjoelnir:robb 28.12 17:13:29 # mount_mfs -s 4194304 swap /tmptmp > mjoelnir:robb 28.12 17:13:43 # df -h /tmptmp > Filesystem SizeUsed Avail Capacity Mounted on > mfs:23190 1.9G1.0K1.8G 1%/tmptmp That was as root though, so maybe that's not such a great test. Is it possible to do something like "doas daemon ..."? I'll switch fstab back to use this size for /tmp and check after the next reboot if it gets mounted as expected ... Cheers, Robb.
Re: Post (snap) update emails: fsck errors and (in)security output
On Thu, Dec 21, 2023 at 10:54:14AM -, Stuart Henderson wrote: > On 2023-12-20, Why 42? The lists account. wrote: > > > > 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 SizeUsed Avail Capacity Mounted on > > mfs:75507 1.9G1.0K1.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. > > login.conf used to allow unlimited datasize for the 'daemon' class. That was > changed to cap at 4G Actually the value is an architecture dependent setting. On amd64 it is indeed 4G, but typically 1024 Mb on the smaller archs which until recently, (post 7.4), included i386, which has now been increased to 1500 Mb. BTW, we already had this exact same discussion with Robb on the list back in February: https://marc.info/?l=openbsd-misc=167561903118994 So when I asked why he didn't just bump the value, it was indeed a question and not a suggestion to just do it.
Re: Post (snap) update emails: fsck errors and (in)security output
On 2023-12-20, Why 42? The lists account. wrote: > > 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 SizeUsed Avail Capacity Mounted on > mfs:75507 1.9G1.0K1.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. login.conf used to allow unlimited datasize for the 'daemon' class. That was changed to cap at 4G (IIRC that was a prerequisite before we were allowed to bump MAXDSIZ but I don't remember all the details now). This affects things started from rc - the things particularly likely to run into memory limits here are fsck, mounting mfs filesystems, maybe also running dump or restore from single user mode - also ports daemons, though in most cases we now provide a separate /etc/login.conf.d/daemonname file which raises limits where needed. If you have plenty of RAM you may want to bump that value.
Re: Post (snap) update emails: fsck errors and (in)security output
On Thu, Dec 21, 2023 at 12:16:33AM +0200, Mihai Popescu wrote: > > Why didn't you just bump the daemon datasize in /etc/login.conf to the > > required value? > > this is there for a reason and if you keep "bumping" it, maybe it should be > removed. OK, then: 1. Read the docs and source. 2. Make an educated and informed decision whether to bump it or not based on your own particular requirements and knowledge level. 3. Don't complain on the official OpenBSD lists if you break your own machine, or expect assistance with such a highly customisted configuration.
Re: Post (snap) update emails: fsck errors and (in)security output
> Why didn't you just bump the daemon datasize in /etc/login.conf to the > required value? Because The Creator said once this is there for a reason and if you keep "bumping" it, maybe it should be removed.
Re: Post (snap) update emails: fsck errors and (in)security output
On Wed, Dec 20, 2023 at 07:55:29PM +0100, Why 42? The lists account. wrote: > When I halved the size (memory) allocated (-s=2097152) it mounts > successfully Why didn't you just bump the daemon datasize in /etc/login.conf to the required value?
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 SizeUsed Avail Capacity Mounted on mfs:75507 1.9G1.0K1.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.
Re: Post (snap) update emails: fsck errors and (in)security output
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 bin19608 Nov 30 15:36:53 2023 /usr/bin/su -r-sr-xr-x 1 root bin19608 Dec 19 08:35:27 2023 /usr/bin/su -r-xr-sr-x 1 root tty17936 Nov 30 15:36:54 2023 /usr/bin/wall -r-xr-sr-x 1 root tty17936 Dec 19 08:35:28 2023 /usr/bin/wall -r-xr-sr-x 1 root tty14184 Nov 30 15:36:55 2023 /usr/bin/write -r-xr-sr-x 1 root tty14184 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 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
Post (snap) update emails: fsck errors and (in)security output
... 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? 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 bin19608 Nov 30 15:36:53 2023 /usr/bin/su -r-sr-xr-x 1 root bin19608 Dec 19 08:35:27 2023 /usr/bin/su -r-xr-sr-x 1 root tty17936 Nov 30 15:36:54 2023 /usr/bin/wall -r-xr-sr-x 1 root tty17936 Dec 19 08:35:28 2023 /usr/bin/wall -r-xr-sr-x 1 root tty14184 Nov 30 15:36:55 2023 /usr/bin/write -r-xr-sr-x 1 root tty14184 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? 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? 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 *
