My system: Fedora Core 2
A few days ago I was infront of a trivial problem, which I never solved before. I had to create some shared space (without quotas or other fancy stuff) on my Linux partition. I needed any user, who belongs to given group, to be able to have full control to that space.
I started with creating group ‘users’ and adding the needed users to it. After that (as root) I created the folder ‘/home/SHARED’, and I
chown -R root:users /home/shared
After that I logged on with another user (who belongs to ‘users’) and – whoops – it was not working. Permission denied. I double-checked the permissions, but all seemed correct.
I got mad. I though I *knew* these things – it should not happen like that. Maybe my madness stopped me from finding the solution of the problem right now, but I tried tons of stuff/experiments – and nothing! The other user could not write to that shared place! I got completely mad! If you would like to know how mad I was, just have in mind that I had crazy thoughts digging through the source of chown or chmod commands in order to understand how the permissions work :(. Fortunately, I did not started with that – I just went to bed. Before that I switched off the machine.
This morning – suprisingly, it worked! I still do not uderstand how and why (the hell) it needed that restart – maybe you could help me? But I was lucky – my friend Nikola Antonov was online, and I asked him that question. He supposed that the yesterday’s user should be logged off/logged on in order new permissions to be taken into account? I still do not believe that.
The fact is that now the shared space works fine. There was just one small problem, which Nikola showed me how to remove (and that’s why I decided to share in English my experience with you). The problem was that though it was shared space, if user A creates a folder, user B (both A and B are in ‘users’ group) cannot delete that folder if it’s not empty. If it’s empty – all works. That was because when creating the folder by A, the newly created object gets owner A:A, and not A:users. Invoking the command
chmod -R g+s
solved that problem too – now when whoever creates an object there, this object has as owner
Actually, Nikola’s guess about the user needing to log off is completely correct. When a process tries to access some filesystem object, the kernel determines whether to allow it or not based on the process’s current effective user ID and group access list. The group access list is modified (actually, set) by the setgroups(2) syscall in login(1) (or login(8), depending on your OS). Thus, once you log in, your group membership is “set in stone” for all commands and processes executed from your login shell. If you modify a user’s group membership in /etc/passwd, /etc/group, etc, those changes will *not* affect the user’s currently-logged-in sessions – this explains why things didn’t work before the reboot 🙂