0

Initial statement

I was installing open source ntfs-3g on my mac (Catalina). At some point, while crsutil was enabled (i.e. System Integrity Protection was on) , I had to modify one line in the ntfs-3g package and I couldn't write on the file due to the crsutil protection (I was using vim).

However, I found this answer https://superuser.com/a/1518414/1220896. With nano, I could modify the "protected" file without any reboot nor switching crsutil to disable.

And now, I am still trying to figure out how sudo nano can bypass SIP while sudo vim or any other text editor can't (update by the author: here I make the mistake of assuming it was SIP related).

Complete command:

sudo nano /usr/local/sbin/mount_ntfs

/usr/local/sbin/mount_ntfs is a soft link to /usr/local/Cellar/ntfs-3g/2017.3.23_3/sbin/mount_ntfs. In order to create the soft link, I had performed the csrutil disable/enable.

output of ls -ls /usr/local/sbin/mount_ntfs

0 lrwxr-xr-x  1 user  admin  45 Sep 18 16:33 /usr/local/sbin/mount_ntfs -> ../Cellar/ntfs-3g/2017.3.23_3/sbin/mount_ntfs

output of ls -ls /usr/local/Cellar/ntfs-3g/2017.3.23_3/sbin/mount_ntfs

8 -r-xr-xr-x  1 user  admin  613 Sep 19 14:17 mount_ntfs

Any idea ?

Update

The problem doesn't come from SIP as pointed out by the contributors to this question. I mark this question as solved and will try to find out why sudo vim could only access the file in readonly despite the permissions being well set.

I thank you all for your input.

As a personal not, i would say that sometimes being on the wrong path doesn't mean you can't learn from it --- consider this when replying to someone misleaded like I was.

Improve this question
7
  • 3
    What was the exact name and location of the file you were editing? I do not believe that sudo nano can bypass SIP and there is probably a logical explanation, but without duplicating exactly what you did, I'll wait till I replicate what you did. – user3439894 Sep 19 '20 at 15:21
  • There's no way for third-party software to install files anywhere that would be protected by SIP. So whatever the reason was that vim couldn't write to the file, it wasn't SIP. – benwiggy Sep 19 '20 at 15:43
  • This is an XY question and should probably be closed.. We need an entirely new focused question for us to help with the real issue that’s pointed out. No one can guess which file is being edited, here. – bmike♦ Sep 19 '20 at 15:43
  • Thank you for your feedback. I will write a detailed story of what happened, specify the files and see if csrutil is actually involved. Maybe as said @bmike, it is not related and just a vim issue. I am still surprised that one tool can have rw authorization and another not, for me rw mod was user/group specific and not app specific, maybe I am wrong... Hold on until I edit on this to reply. – A.G. Sep 20 '20 at 9:55
  • 1
    The target file and its symlink is not protected by System Integrity Protection and therefore the whole premise of this question is null and void, – user3439894 Sep 20 '20 at 10:17
1

/usr/local is Writable

The file path /usr/local/sbin/mount_ntfs is not protected on macOS. If a specific tool or application can not write to this file, that tool or application is at fault.

/usr/local is not protected by macOS's System Integrity Protection:

About System Integrity Protection on your Mac

...

System Integrity Protection includes protection for these parts of the system:

  • /System
  • /usr
  • /bin
  • /sbin
  • /var
  • Apps that are pre-installed with OS X

Paths and apps that third-party apps and installers can continue to write to include:

  • /Applications
  • /Library
  • /usr/local
Improve this answer
1
  • Thank you, it is very clear. I guess, I didn't have a good friend to explain it to me to begin with. – A.G. Sep 20 '20 at 12:59
1

SIP doesn’t matter so much on Catalina. The system volume is read only / protected.

When you say crsutil was enabled, that is meaningless. That tool is always enabled and can run. You would need to report the full status it reports and then reboot the Mac and then specify the full path to a specific file you attempted to modify for someone to be able to check your work.

I would just set aside all the history and ask a follow on question showing your precise vim failure. That’s quick for people to answer whereas trying to teach anyone how SIP works takes about 2 hours and constant feedback to cover all the nuances. Far too broad for a question here other than the idea to ask a follow up question that documents the specifics.

Improve this answer
1
  • I will follow your recommendation. – A.G. Sep 20 '20 at 13:18

You must log in to answer this question.

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