Date: Sun, 25 Feb 2024 06:45:39 -0000 (UTC) From: "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org> To: freebsd-stable@freebsd.org Subject: Re: gpart device permissions security hole (/dev/geom.ctl) Message-ID: <slrnutlogj.27vp.pmc@disp.intra.daemon.contact> References: <ZdE2Hm6y5Fel2etP@marble.hightek.org> <slrnutei1n.1ebh.pmc@disp.intra.daemon.contact> <Zde7TAehUyMvDQ5F@marble.hightek.org> <2421f1a5-d924-4912-abff-e000e41f5459@quip.cz> <ZdpK6ltoUgnTSmba@marble.hightek.org> <4de9c605-c93d-4286-a402-0bc52e9d62ff@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2024-02-24, Miroslav Lachman <000.fbsd@quip.cz> wrote: > On 24/02/2024 21:00, Vincent Stemen wrote: >> On Sat, Feb 24, 2024 at 04:40:00PM +0100, Miroslav Lachman wrote: >>> I agree with this security problem. Just a small note - there are >>> backups of partitions (/var/backups/gpart.*) created by periodic script >>> /etc/periodic/daily/221.backup-gpart (if you have >>> daily_backup_gpart_enable="YES" in your /etc/periodic.conf or in a >>> /etc/defaults/periodic.conf which is the default). That way you can get >>> back the number plate on you house in some cases. >> >> Thanks. That's good to know. I was not aware of those features of >> periodic. > > Almost nobody knows. Oh, now I see why there is a problem. Actually I found the partition tables missing when I planned for desaster recovery, and thought it would be helpful to have a copy of them. So I implemented such periodic backup long before it was officially provided. I think there are many possibilities how things can go wrong, and evil action is only one of them. So my first imperative is to get the data savely into backup (and then the backup to offsite). That accomplished, we can in a relaxed mood think about what we will do to the person who actually manages to delete the partition table... cheerio, PMc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnutlogj.27vp.pmc>