3

I am an "admin" user on a Mac running Big Sur. I am trying to remove a symlink:

$ ls -al /usr/bin/python
lrwxr-xr-x  1 root  wheel  75 Jan  1  2020 /usr/bin/python -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7

Now, I tried removing it with sudo but I get permission denied:

$ sudo rm /usr/bin/python
rm: /usr/bin/python: Operation not permitted

How do I assume actual admin power on my mac? Do I need to be added to the "wheel" group?

Please note, I am well aware of workarounds with shell aliases as outlined here:

Unable to upgrade to python 3.6 from python 2.7

But that would only be a work around. I want to know what the root cause is, and what I can do about it.

Improve this question
4
  • 2
    You can't on big Sur. All system files are on a read only disk. Also removing that python will break some system programs that are needed eg xattr
    – mmmmmm
    Aug 23, 2021 at 19:40
  • Wow. Do you have a good resource on how Big Sur manages system updates and such?
    – Lucky
    Aug 23, 2021 at 19:43
  • 2
    You should not do anything about it. On macOS, it is normal to run V3.x python with command python3. The command python should remain the inbuilt V2.x.
    – Gilby
    Aug 24, 2021 at 3:58
  • 1
    Welcome to Ask Different. Why not install your tools in the user modifiable places? This seems like it might be an XY problem.
    – bmike ♦
    Aug 24, 2021 at 12:02

3 Answers 3

Reset to default
6

The root cause here is that the /usr/bin directory is protected by SIP (System Integrity Protection). Therefore noone, even admin users, can change the contents of the directory while SIP is active.

The system folders on Big Sur are actually contained on a separate, cryptographically signed file system (system volume) that is mounted read-only at boot. Its contents is mixed into your normal read-write mounted file system through the use of so called firmlinks. This means that it looks and feels like it used to do on older versions of macOS - everything is in the right place so to speak - but in actual fact the system files cannot be changed during normal system operation.

In theory, you could disable SIP, mount the system volume as writable, change the python link and re-sign the whole thing. However, I would strong discourage that as you would risk breaking Apple-supplied tools that depend on the specific python version - and you would probably have to fight a never-ending battle where the link is restored during macOS upgrades.

Instead I would advise you to either use a different name for the program (i.e. for example python3 instead of python) - or using an alias in your shell so that "python" really runs a differently named program.

Improve this answer
9
  • 1
    I prefer dangerous freedom, but to each their own
    – Lucky
    Aug 23, 2021 at 19:50
  • 5
    I don't know if I would call that freedom exactly - but you are ofcourse free to do whatever you want with your own computer (within the limits of the law). If that means disabling core security features or creating extra jobs to be done during upgrades - that's perfectly fine. Just take a minute to understand the risk and the work involved before starting - and remember to keep backups! :-)
    – jksoegaard
    Aug 23, 2021 at 19:53
  • 4
    @Lucky Replacing the system version of Python may break system scripts that are written for Python 2 rather than Python 3. It's much safer to install your preferred version of Python somewhere else (e.g. /usr/local/bin/), and make sure that's before /usr/bin in your PATH (which it is by default).
    – Gordon Davisson
    Aug 23, 2021 at 19:55
  • 4
    It's been normal unix practice for more than 30 years that if you want a different version of a system program put it somewhere not under /usr except /usr/local and change PATH and/or aliases. /usr belongs to the vendor eg Sun HP Next DEC etc
    – mmmmmm
    Aug 23, 2021 at 19:56
  • 1
    What version of python and from where are you installing that cares whether or not the system python is there or not? Downloads from python.org, MacPorts, even Homebrew don't care.
    – Marc Wilson
    Aug 23, 2021 at 20:06
0

Reading the comments, the answer to the larger, not explicitly asked question of “What has Apple done to secure the OS and also allow developers to overlay versions of command-line tools to do their work?”

If you have that question: the best writing in the evolution of command line relevant changes from Mojave to Catalina to Big Sur is here:

The first half-dozen paragraphs lay out clearly what is up and will help greatly anyone looking to customize a modern macOS system.

The signed and read-only system volume will break many old guides and answers since some traditional unix assumptions are no longer valid (like the need to be root or what an admin might do to modify system files in general).

Improve this answer
7
  • 2
    I wouldn't say that "traditional unix assumptions are no longer valid" as such. That /usr is read-only is actually how it used to be on most Unix systems. The FHS still allows that today, and some also do that on typically "not-so-Unix-like-Unix-systems" such as Linux.
    – jksoegaard
    Aug 24, 2021 at 12:15
  • You would not agree that some assumptions are no longer valid? @jksoegaard
    – bmike ♦
    Aug 24, 2021 at 12:25
  • 1
    This was specifically about not being able to modify /usr because it is read-only. If you're used to older macOS versions, then yes, that would break your assumptions. However, if you only have "traditional unix assumptions" - you would not be surprised at all to find that /usr is read-only.
    – jksoegaard
    Aug 24, 2021 at 12:29
  • 1
    I disagree. When I started using unix on the desktop, sudo rm /usr/bin/whatever would have worked despite read only permissions on the filesystem. But that was before python was invented, so maybe our definition of traditional unix aren’t in alignment?
    – bmike ♦
    Aug 24, 2021 at 20:57
  • 1
    Read-only permissions on a file and a file system that is mounted read-only are two very different things. /usr being mounted read-only on various Unixes was fairly common. Perhaps you're remembering something differently because of the time that has passed? - I assume you meant that you were using Unix on the desktop in the mid 80's. My experience with Unix (mostly servers) started a bit later in the early 90's, and I clearly recall having /usr mounted read-only on HP-UX and AIX machines. I also remember it being quite common that we had Solaris workstations with /usr mounted read-only [...]
    – jksoegaard
    Aug 24, 2021 at 21:16
0

You can issue the:

csrutil disable

command to disable System Integrity Mode (SIM).

then, while in recovery mode stil:

sudo rm -rf /target

Disabling SIM is generally frowned upon and I recommend learning about it before following up with this strategy. I decided to go ahead and do it and am satisfied with the result.

Improve this answer
1
  • No: only if the file is on the Data volume, not as of 11.7.x if the file is anywhere on the System volume, see the EclecticLight writeup @bmike links "Immutable system files now reside on the System volume, which not only has complete protection by SIP, but is normally mounted read-only." Not unless you also (permanently, irreversibly) deactivate FileVault/SSV (not recommended) and also do csrutil authenticated-root disable, them mount rw using a link.
    – smci
    Jan 27 at 3:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .