tinytex icon indicating copy to clipboard operation
tinytex copied to clipboard

fix filesystem security issues

Open r2evans opened this issue 11 months ago • 0 comments

From https://github.com/rstudio/tinytex/issues/24#issuecomment-372043672:

/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 directory1, 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.

r2evans avatar Feb 01 '25 16:02 r2evans