4 ms·

> Consider this command: # pkg delete -af > [...] > What the same "pkg delete -af" command does on a PKGBASE FreeBSD system? > It kills/destroys almost

by 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.
      - josefx 1y ago
        You already have to login as root to modify fundamental os files and any modification can break things just as baldy as rm can.
    - charcircuit 1y ago
      I agree, but rm doesn't have to be the thing to modify system files.
  - ender341341 1y ago
    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".
    - serbuvlad 1y ago
      Ah, the beauties of the POSIX shell.
    - riffraff 1y ago
      I think a valid interpretation of GPs point could be that top-level folders should have special properties so that they're not at risk of a bad rm, e.g. xattr "unchangeable" flags. The fact that you can accidentally nuke the system seems a remnant from the olden days which we should have corrected a long time ago. (I think GNU did a valid mitigation with preserve-root, just musing philosophically.)
      - delamon 1y ago
        "immutable" top-level folders won't cut it. In order to recursively delete a folder, rm has to delete leaves first. So, you will endup with empty top-level folders, which is no better.
        charcircuit 1y ago
        >rm has to delete leaves first There is nothing fundamental with rm for it to work like that.
        lmz 1y ago
        It does if you ever want rmdir to succeed.
  - serbuvlad 1y ago
    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.
    - charcircuit 1y ago
      >not about their OS internals Yes, they do. Users definitely care about their system being able to properly boot and work correctly. It's unnaceptable how Linux distros make you use a live usb to go in and fix them instead of having a built in way to the OS for it to recover from bad things happening.
  - hulitu 1y ago
    > rm should not have permission to break the operating system. It doesn't. You must su to root to "achieve" that.
  - yjftsjthsd-h 1y ago
    > 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.
    - charcircuit 1y ago
      >and then told it to wipe its own disks This can be done via a dedicated factory reset or wipe feature. It doesn't need to be the responsibility of rm.
      - yjftsjthsd-h 1y ago
        It sounded like you were arguing that no program should be able to do it, which makes it somewhat difficult to implement a wipe feature. (And whatever wipe/reset feature we have needs to be done by some operating system, because a solution that requires adding new features to everything's firmware is a non-starter in practice)
- deleted 1y ago
  [deleted]
- inopinatus 1y ago
  reminds me of that time a colleague (and FreeBSD committer) proposed su --with-wheel-group for gnu coreutils
- throw0101d 1y ago
  > 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 1y ago
    > 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 1y ago
  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 1y ago
    Some "RTFM" for you :) https://www.zeugmaweb.net/misc/unix/admin-horror.html https://www.zeugmaweb.net/misc/unix/admin-horror.html
znpy 1y ago
What is POLA in this context?
- phkamp 1y ago
  POLA = Principle Of Least Astonishment
  - grahamjperrin 1y ago
    I think, messe means that removal is _not_ astonishing, if removal is not simply requested. Removal is forcibly requested. The force means, remove more than what's normal. An abnormal removal.

by messe 1y ago

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.
    - josefx 1y ago
      You already have to login as root to modify fundamental os files and any modification can break things just as baldy as rm can.
  - charcircuit 1y ago
    I agree, but rm doesn't have to be the thing to modify system files.
- ender341341 1y ago
  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".
  - serbuvlad 1y ago
    Ah, the beauties of the POSIX shell.
  - riffraff 1y ago
    I think a valid interpretation of GPs point could be that top-level folders should have special properties so that they're not at risk of a bad rm, e.g. xattr "unchangeable" flags. The fact that you can accidentally nuke the system seems a remnant from the olden days which we should have corrected a long time ago. (I think GNU did a valid mitigation with preserve-root, just musing philosophically.)
    - delamon 1y ago
      "immutable" top-level folders won't cut it. In order to recursively delete a folder, rm has to delete leaves first. So, you will endup with empty top-level folders, which is no better.
      - charcircuit 1y ago
        >rm has to delete leaves first There is nothing fundamental with rm for it to work like that.
        lmz 1y ago
        It does if you ever want rmdir to succeed.
- serbuvlad 1y ago
  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.
  - charcircuit 1y ago
    >not about their OS internals Yes, they do. Users definitely care about their system being able to properly boot and work correctly. It's unnaceptable how Linux distros make you use a live usb to go in and fix them instead of having a built in way to the OS for it to recover from bad things happening.
- hulitu 1y ago
  > rm should not have permission to break the operating system. It doesn't. You must su to root to "achieve" that.
- yjftsjthsd-h 1y ago
  > 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.
  - charcircuit 1y ago
    >and then told it to wipe its own disks This can be done via a dedicated factory reset or wipe feature. It doesn't need to be the responsibility of rm.
    - yjftsjthsd-h 1y ago
      It sounded like you were arguing that no program should be able to do it, which makes it somewhat difficult to implement a wipe feature. (And whatever wipe/reset feature we have needs to be done by some operating system, because a solution that requires adding new features to everything's firmware is a non-starter in practice)
deleted 1y ago
[deleted]
inopinatus 1y ago
reminds me of that time a colleague (and FreeBSD committer) proposed su --with-wheel-group for gnu coreutils
throw0101d 1y ago
> 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 1y ago
  > 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 1y ago
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 1y ago
  Some "RTFM" for you :) https://www.zeugmaweb.net/misc/unix/admin-horror.html https://www.zeugmaweb.net/misc/unix/admin-horror.html

znpy 1y ago

What is POLA in this context?

phkamp 1y ago
POLA = Principle Of Least Astonishment
- grahamjperrin 1y ago
  I think, messe means that removal is _not_ astonishing, if removal is not simply requested. Removal is forcibly requested. The force means, remove more than what's normal. An abnormal removal.