0

I've put things in /Users/Shared that I want my wife and I to have full access to, no matter which of us creates/reads/edits. I've tried to ensure this by setting group to rwx. Now, we're both in the same group, but just to be sure, I put the group sticky bit on, making it rws. Both of these were done recursively. But when I looked at it today, the sticky bit was not on anything.

Has Apple added another nanny feature to "protect" us from ourselves? Our could this have been done by an installer that asked for an admin password?

Can I prevent it with an ACL?

WGroleau
  • 3,947
  • 6
  • 34
  • 66
  • I don't know of anything that'd remove sticky bits, but they're not what you want anyway -- they deny delete access to anyone except the owner (creator) of a file, thus limiting sharing. You want an ACL to grant group access -- see [this question](https://apple.stackexchange.com/questions/5689/permissions-for-new-files-in-shared-directory). – Gordon Davisson Jun 21 '19 at 19:22
  • My experience with Unix variants at work for over thirty years agrees with https://en.wikipedia.org/wiki/Setuid#When_set_on_a_directory saying "Setting the setgid permission on a directory ("chmod g+s") causes new files and subdirectories created within it to inherit its group ID, rather than the primary group ID of the user who created the file (the owner ID is never affected, only the group ID)." – WGroleau Jun 21 '19 at 20:29
  • The ACL suggestion in answer to that question has the disclaimer that it does not apply to files moved into that directory. – WGroleau Jun 21 '19 at 20:32
  • Correction: more than twenty years; the last ten before retirement, I was required to use Windows. (Although I frequently moved things to my Mac to do them more efficiently.) – WGroleau Jun 21 '19 at 21:26
  • sticky bit != setgid; I read "sticky" in the question, but apparently you actually set the setgid bit. This is essentially irrelevant on macOS, since it *always* sets group based on the folder the item is created in, rather than from the user's primary group. And since the default perms for new items is rw-r--r-- (rwxr-xr-x for folders), the group doesn't get write access anyway. That's why, in the linked answer, I said you can't achieve what you want with POSIX-style permissions. – Gordon Davisson Jun 21 '19 at 21:44
  • OK, we always called both the owner on and the group one “sticky bit” where I worked. And the default umask for us (in our .profile and .bashrc) is 664. – WGroleau Jun 22 '19 at 03:20
  • Anyway, the issue is something unwanted changing the modes. – WGroleau Jun 22 '19 at 03:23
  • I don't know of anything that'd do that (although I wouldn't be surprised if programs didn't preserve permissions when re-saving). You can use `ls -lc` to see when a file was last "changed" (which includes permissions changes) -- that might give a hint. – Gordon Davisson Jun 22 '19 at 04:11
  • It's the entire /Users/Shared tree, though. I never use anything on the entire directory except the few times I've used sudo for a recursive `chmod` or `chgrp` – WGroleau Jun 22 '19 at 04:26

0 Answers0