Pkgbase Removes FreeBSD Base System Feature
37 comments
·July 30, 2025messe
yjftsjthsd-h
There's an interesting analog to GNU rm having --preserve-root/--no-preserve-root ... Is it more or less surprising for `rm -rf /` to be special? (This isn't meant as advocating one side or the other; I think it's a genuine point of philosophical tension.)
throw0101d
> Is it more or less surprising for `rm -rf /` to be special?
A few years the POSIX folks declared that the behaviour of `rm -rf /` nuking the entire file system is a bug.
IIRC, one of the Sun Solaris folks (Cantrill? Gregg? Other?) thought the behaviour was dumb and argued successfully that it should not be work that way. Any implementation that does it is not POSIX-compliant.
hulitu
> A few years the POSIX folks declared that the behaviour of `rm -rf /` nuking the entire file system is a bug.
Yes. PEBKAC bug. /s
pjmlp
Once upon a time I nuked a GNU/Linux installation exactly with that command, due to a finger race between backspace and return keys.
hulitu
Some "RTFM" for you :)
null
inopinatus
reminds me of that time a colleague (and FreeBSD committer) proposed su --with-wheel-group for gnu coreutils
charcircuit
rm should not have permission to break the operating system. If a program can break the operating system that is a failure in the operating system's sandboxing or permissions. no-preserve-root tries to solve the issue at the wrong layer of the stack and only adresses one way to break the os. Being special to just / doesn't make sense to me.
ender341341
It's treated special cause most shells handle undefined variables as empty strings so `rm -rf "${base_path}/${sub_dir}"` can turn into `rm -rf '/'` and users commonly don't expect that.
While that case may be simple to catch the writers of gnu rm also recognize that scripts tend to not be well tested and decided "better than it currently is" is better than "we didn't do any mitigations to a common problem cause the solution wasn't perfect".
yjftsjthsd-h
> no-preserve-root tries to solve the issue at the wrong layer of the stack and only adresses one way to break the os. Being special to just / doesn't make sense to me.
I could see that making sense. Maybe a "really important core OS" attribute? (I wouldn't want `rm /bin/sh` to run without forcing either.)
However,
> If a program can break the operating system that is a failure in the operating system's sandboxing or permissions.
Not necessarily. I have on multiple occasions logged into a machine, gotten a root shell, and then told it to wipe its own disks (either by block discard, or just dding over with /dev/null). That is a legitimate use that should work.
josefx
At some point you have to give something the ability to update and modify system components and even then it is extreemely unlikely that deleting everything starting with / is the intended behavior.
hulitu
> rm should not have permission to break the operating system.
It doesn't. You must su to root to "achieve" that.
serbuvlad
Why?
Obviously rm -rf / will only "destroy the operating system" if the user is root and we're in the root namespace. There is nothing stopping you from building a sandboxed OS that never gives your users real root (Android).
But what'd be the point of that? Users care about their data, not about their OS internals. If the OS blows, that's just an OS reinstall. But if a non-backed-up /home blows, that could be months of work. And any program that can delete a file in /home (as they need to be able to do to allow the user to do everyday work) can also delete all of them.
o11c
For information on what this is even about, see https://wiki.freebsd.org/PkgBase
Notably it is explicitly marked as experimental; teething problems are to be expected.
BSDobelix
I would really like to have those pkg's and the programm (pkg) separated, for example:
For the system the program "pkgs" ("s" for system) can write to /bin /sbin etc, and can only install/remove .pkgs (system packages)
For port's (can only write to /usr/local) pkg and .pkg
With that we can have the same separation as we have now, for me that's a big plus on the BSD side of things. BTW Windows, Android and MACOS have some kind of that separation too.
pkg delete -af removes all "port" pkg's
pkgs delete (has no option -a but options like IDS from freebsd-update where every installable file IN the package (a *.pkgs) has a checksum instead just the pkg itself)
Drivers/Firmware will then have to move to pkgs, also we can have different groups for maintaining the system and port (root/wheel for pkgs and operator for pkg)
Also packaging error's in port packages cannot damage your system.
altairprime
OP, since you wrote this email to the FreeBSD list, posted a GitHub issue, and posted this to HN — is this something you’ve been submitting patches for but they’re being ignored? Could you tell us more about why this is important to you in specific?
JdeBP
As Graham Perrin pointed out in a reply, there are more such bugs in FreeBSD's pkgbase experiment. They were opened months ago, and they're still open. This is not a finished mechanism. Very clearly not. (-:
yjftsjthsd-h
I mean, isn't the point to remove the distinction? If you tell apt/dnf/zypper/apk/... to remove everything, then the thing that will stop you isn't the base OS being separate, it's that they mark the core packages as special and require you to force the matter. (And I agree with the other commenter that this should be done for pkg but that's why it's experimental right now)
JdeBP
This would be learning from the prior experience of others.
In particular, learning why Debian has a system of marking some packages as "essential"; and learning why tools like aptitude, when told to resolve an intended change set up in the UI into specific package actions, will start doing that by switching off attempts to remove "essential" packages.
Note from the thread that there is an idea of marking packages as "vital", but it is not a concrete one yet.
jmclnx
This is from vermaden, who's site has a lot of informative very good FreeBSD information.
I remember in the 8x days, there was talk of moving parts or all of base installable via pkg. That server had a heat death and I have yet to replace it, so I have been out of the FreeBSD world for a while. At the time it was just being proposed.
I wonder if that has been completed or is this a first step to doing that ?
badgersnake
[flagged]
> Consider this command:
> [...]> What the same "pkg delete -af" command does on a PKGBASE FreeBSD system?
> It kills/destroys almost all of the FreeBSD Base System [...]
> POLA is the principle that made FreeBSD such predictable system. Where is the POLA now?
IMO if you convert the base system to be installed via packages and then force delete all packages, then the principle of least astonishment says that you'll delete most of the base system too.