Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix filesystem security issues #463

Open
r2evans opened this issue Feb 1, 2025 · 0 comments
Open

fix filesystem security issues #463

r2evans opened this issue Feb 1, 2025 · 0 comments

Comments

@r2evans
Copy link

r2evans commented Feb 1, 2025

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 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant