5 ms·

Pkgbase Removes FreeBSD Base System Feature

31 points by vermaden 1y ago

o11c 1y ago
For information on what this is even about, see https://wiki.freebsd.org/PkgBase https://wiki.freebsd.org/PkgBase Notably it is explicitly marked as experimental; teething problems are to be expected.
yjftsjthsd-h 1y ago
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 1y ago
  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.
  - grahamjperrin 1y ago
    I suspect that at least one of the numerous threads has sown seeds of confusion about the vital flag. Here's not the place to undo this … sorry.
messe 1y ago
> Consider this command: # pkg delete -af > [...] > 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.
- yjftsjthsd-h 1y ago
  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.)
  - charcircuit 1y ago
    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.
    - josefx 1y ago
      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.
      - mcherm 1y ago
        An EXTRA flag to rm could be required in order for it to be able to modify fundamental os files. This would eliminate nearly all accidents.
        dspillett 1y ago
        Though that requires rm to know what objects are fundamental. While there are some obvious static choices there are many others that are going to vary between installations. You could add extended attributes to indicate what is what, but that is an extra complication for distro maintainers. You could use the immutable flag though again that will be a faf for upgrades (remove flags, update files, replace flags). Once rm is protecting users in this way, there might be an expectation that other tools will too, but the time you get to this point rather than reinventing the while, perhaps just use something like selinux (I assume BSD has an equivalent capabilities based option?) and other existing control features. rm having --preserve-root on by default is I think a simple mitigation that protects against the most common potential accidents than any of the above would protect from, and if something more than that is wanted then things like the immutable flag already exist and would cover far more than just rm.
badgersnake 1y ago
[flagged]
JdeBP 1y ago
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. (-: * https://github.com/freebsd/pkg/issues/2414 https://github.com/freebsd/pkg/issues/2414
- grahamjperrin 1y ago
  > https://github.com/freebsd/pkg/issues/2414 https://github.com/freebsd/pkg/issues/2414 I wrote: "2414 intrigues me, however there's not enough for me to tell whether it's a pkg issue. "I do know that the big picture includes things being suitably prioritised; for this reason, and others, I have felt no need to bump 2414. "If additional info is required, they'll ask me in due course." – <https://www.reddit.com/r/freebsd/comments/1mct33f/comment/n641jnk/ https://www.reddit.com/r/freebsd/comments/1mct33f/comment/n6...>
- grahamjperrin 1y ago
  You may be unaware of the numerous freebsd-update bugs that will never be fixed. With regard to pkgbase, > … Graham Perrin … not a finished mechanism. Very clearly not. (-: My experience with pkgbase is clearly very different from your perspective. <https://lobste.rs/s/ikhfqq/pkgbase_removes_freebsd_base_system#c_vqcdnj https://lobste.rs/s/ikhfqq/pkgbase_removes_freebsd_base_syst...>: "… I should describe the pkgbase caboodle as ninety-eight percent production-ready. The official packages for FreeBSD-RELEASE have always been _one hundred percent_ production quality. Very few aspects of pkgbase are experimental."
altairprime 1y ago
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?
BSDobelix 1y ago
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.
jmclnx 1y ago
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 ?
- grahamjperrin 1y ago
  The FreeBSD Project began providing official packages – for RELEASE and for CURRENT – in October 2023.

31 points by vermaden 1y ago

o11c 1y ago

For information on what this is even about, see https://wiki.freebsd.org/PkgBase https://wiki.freebsd.org/PkgBase Notably it is explicitly marked as experimental; teething problems are to be expected.

yjftsjthsd-h 1y ago

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 1y ago
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.
- grahamjperrin 1y ago
  I suspect that at least one of the numerous threads has sown seeds of confusion about the vital flag. Here's not the place to undo this … sorry.

messe 1y ago

> Consider this command: # pkg delete -af > [...] > 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.

yjftsjthsd-h 1y ago
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.)
- charcircuit 1y ago
  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.
  - josefx 1y ago
    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.
    - mcherm 1y ago
      An EXTRA flag to rm could be required in order for it to be able to modify fundamental os files. This would eliminate nearly all accidents.
      - dspillett 1y ago
        Though that requires rm to know what objects are fundamental. While there are some obvious static choices there are many others that are going to vary between installations. You could add extended attributes to indicate what is what, but that is an extra complication for distro maintainers. You could use the immutable flag though again that will be a faf for upgrades (remove flags, update files, replace flags). Once rm is protecting users in this way, there might be an expectation that other tools will too, but the time you get to this point rather than reinventing the while, perhaps just use something like selinux (I assume BSD has an equivalent capabilities based option?) and other existing control features. rm having --preserve-root on by default is I think a simple mitigation that protects against the most common potential accidents than any of the above would protect from, and if something more than that is wanted then things like the immutable flag already exist and would cover far more than just rm.

badgersnake 1y ago

[flagged]

JdeBP 1y ago

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. (-: * https://github.com/freebsd/pkg/issues/2414 https://github.com/freebsd/pkg/issues/2414

grahamjperrin 1y ago
> https://github.com/freebsd/pkg/issues/2414 https://github.com/freebsd/pkg/issues/2414 I wrote: "2414 intrigues me, however there's not enough for me to tell whether it's a pkg issue. "I do know that the big picture includes things being suitably prioritised; for this reason, and others, I have felt no need to bump 2414. "If additional info is required, they'll ask me in due course." – <https://www.reddit.com/r/freebsd/comments/1mct33f/comment/n641jnk/ https://www.reddit.com/r/freebsd/comments/1mct33f/comment/n6...>
grahamjperrin 1y ago
You may be unaware of the numerous freebsd-update bugs that will never be fixed. With regard to pkgbase, > … Graham Perrin … not a finished mechanism. Very clearly not. (-: My experience with pkgbase is clearly very different from your perspective. <https://lobste.rs/s/ikhfqq/pkgbase_removes_freebsd_base_system#c_vqcdnj https://lobste.rs/s/ikhfqq/pkgbase_removes_freebsd_base_syst...>: "… I should describe the pkgbase caboodle as ninety-eight percent production-ready. The official packages for FreeBSD-RELEASE have always been _one hundred percent_ production quality. Very few aspects of pkgbase are experimental."

altairprime 1y ago

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?

BSDobelix 1y ago

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.

jmclnx 1y ago

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 ?

grahamjperrin 1y ago
The FreeBSD Project began providing official packages – for RELEASE and for CURRENT – in October 2023.