Fix macOS /usr/local/bin ownership: drop -R, restore after install

[Copilot]

TinyTeX was recursively changing ownership of /usr/local/bin (chown -R) — affecting all pre-existing binaries unrelated to TinyTeX — and never reverting the change.

Changes

R/install.R — check_local_bin()

• Drop -R from chown: change applies to the directory itself only, not its contents
• Capture original owner:group via stat -f '%Su:%Sg' before modifying
• Return a validated cleanup closure; install_tinytex() registers it via on.exit() so ownership is restored after tlmgr path add completes

tools/install-bin-unix.sh

• Same -R removal
• Store original owner:group in PREV_OWNER before chown; restore it unconditionally after tlmgr path add

# Before
osascript(sprintf('chown -R %s:admin %s', user, p))  # recursive, never undone

# After
prev_owner = system2('stat', c('-f', '%Su:%Sg', p), stdout = TRUE)
osascript(sprintf('chown %s:admin %s', user, p))       # directory only
# on.exit() restores: osascript(sprintf('chown %s %s', prev_owner, p))

Original prompt

---

This section details on the original issue you should resolve

<issue_title>fix filesystem security issues</issue_title>
<issue_description>From #24 (comment):

/usr/local/bin should be writable by default on (at least recent versions of) macOS.

Please no 🤦 . No R package should ever automatically/directly change permissions on a file/directory outside of the user's home directory¹, nor encourage it as a long-term solution. Further, your script is changing ownership for files that have nothing at all to do with TinyTex. Lastly, setting up symlinks from /usr/local/bin/ into any user's /Users/*/bin/ is as bad if not worse than changing the ownership of /usr/local/bin/; even if that one user keeps it up to date, it is bad practice and has risks.

There are two ways to do it "responsibly" (from an OS security mindset):

1. Setup a Homebrew formula so that it can be installed and managed in a central location /opt/homebrew/..., usable to all users, and does not allow users to access other users' home directory contents. The presumption here is that the setup of Homebrew is permitted by a local user, and if on a multi-user system, who can do what with brew is for them to decide (not an R package maintainer ... no offense intended).
   I confess that I don't know homebrew well enough to be able to help much with this approach.
2. Initially install completely to a local or temporary location, then use the ocascript "with administrator privileges" trick for moving everything to /usr/local/bin/ and /usr/local/share/TinyTex/, no symlinks required. This supports multi-users just as natively without any fearsome user-directory-breach nor any permanent side-effects such as from chown.

I might be willing to help with number 2, though I apologize it will not happen any time soon. But I think that's a much preferred way-forward than the current method.

As a temporary step, can you do one or more of the following:

1. Add what the original owner/group were changed from? On my system I think it's root:staff but I can't know now. This allows security-obsessed people like me to undo the change to what it was before.
2. There should be no need to recursively change all non-TinyTex contents of /usr/local/bin/ to be owned by me, please remove the -R from chown -R. (This should never have been needed in the first place, this removal should have zero effect on the installation.)
3. Once installation is done, undo the change (using ocascript a second time) on /usr/local/bin/ (again, no need for recursive changes).

^{1: When external non-R software is required, if *that* software has a script that handles multi-user situations, then that is IMO an acceptable solution. No software I've ever installed on linux ever attempted to change ownership of `/usr/local/bin`, for many good reasons. Now that I've moved to MacOS, I continue the unix-y security mindsets, most of which Apple agrees with.}

Comments on the Issue (you are @copilot in this section)

• Fixes fix filesystem security issues #463

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}